Cumulus Support

NOTICE - For existing users already running this php script and finding that any new snow information you entered in CMX 4.2.0 and above has not updated your snow summary on your web page there is now a fix in the snowSumData.php script. Download the file and replace it with the one already installed. ______________________________________________________________________________________________________________________
Updated version: updated 12-03-2024 (Do Not Use with CMX 4.3.0 b4063 and Above)

There is a new version specifically for CMX 4.3 and above. It can be obtained here: viewtopic.php?t=22921

For CMX versions below 4.3
ver 1.1
Fixed issue of not updating snow information on web page from CMX 4.2.0 and above.

Added a new HTML table containing the following items by month; (please see images below)

* Cumulative days with snowfall
* Cumulative snowfall depth
* Average annual snowfall depth
* Probability of snowfall %
* Year with most snowfall and its amount
* Year with least snowfall and its amount

Also re-wrote large portions of the script for better optimization.

Thanks to PaulMy as portions of this script is inspired from komokaweather.com snowfall-log.pdf.

MUST have php installed on the same computer running CumulusMX to use this script. The zip contains the files necessary and a read_me text with install instructions.

Runs successfully in Cumulus MXUI web template and the standard CMX website template. Hasn't been tested on other templates but shouldn't be any reason it wouldn't work. For both templates just add <?php include_once "./snowSummary.php";?> where you where you want it to be displayed. Then for the standard template just change the webpage extension from .htm to .php and update your menu to point the .php page.

PLEASE READ
Since the scripts' function has changed considerably from it's inception, below is a brief explanation of how to enter data so that my scripts will display the desired results.
______________________________________________________________________________________________________________________
In the main CMX program go to "Edit => Weather Diary" where you will find a few fields for entering data. My script does not utilize the comments box section.

--------------------------
Snow Depth text box:
--------------------------
Enter any new snowfall measurement received in a 24 hr period. New snowfall measurements are generally taken once a day usually between 7am and 9am. But use any time you want. The important thing is to try to be consistent for better accuracy. In my script, this text box is only used for recording new measurable snowfall in a 24 hr period. It is not for recording "snow on the ground" or the "snowpack". Since there is only one text box, I had to make a decision. I felt it was more important to know the amount of snow received in a 24 hr period rather than the overall snow on the ground.

----------------------------
SnowFalling check box:
----------------------------
This is used to record days when it snowed but did not amount to any measurable snowfall. This would be considered as Trace snow. When checking this box, nothing is to be entered inside the Snow Depth textbox. This checkbox will record as a snow event and it will add a day to the the Snow Event row in my script.

--------------------------
SnowLying check box:
--------------------------
The only purpose of checking this box is to record a day that there is snow on the ground. This is commonly known as ground cover or snowpack. It's purpose is to keep a count of days that snow was on the ground. This will not count as a snow event and will not be recorded as such. It will however, keep a count of the amount of days snow was on the ground and record it as such in my script as Ground Cover.

This check box may be used with either the SnowFalling check box or the Snow Depth text box. This is because the temps may have been below freezing for several days and there may already be snow on the ground. This allows the ability to record the new snow event, using either the SnowFalling checkbox (if there was only a trace of snow) or the Snow Depth textbox (if there was measurable snow) while at the same time recording the ground cover. Just remember that the Snow Depth textbox is for recording "new snowfall" amounts (events) and not the overall depth of the snow already on the ground (snowpack).
______________________________________________________________________________________________________________________

That's all there is too it. The scripts will do the rest getting it to your website at your website update interval.

snowSummary can be run as a standalone page or as an "include_once" in your template page and it should fire up with minimal effort. Of course your mileage may vary but it should be fairly easy to tweak. This has been tested as best I can but I have no way of testing on public website. If someone wants to try it out on a public site and let me know, I can try to fine tune it as needed.

I am not a programmer. I just fiddle around and sometimes come up with something useful. Anyway, I wanted something to display total snow amounts for each month and total the months up by year. So I began fiddling and came up with this script.

Please feel free to alter it as you see fit and/or improve upon it for simpler adaptability for future CMX upgrades. Feedback is welcome but please remember I am not a programmer. This is a continuing project.


pic of it used as an include in a template showing northern hemisphere:

Same as above but with daily snowfall calendar popup dialog

Here in UK, we call sum of daily snow depths, like in your tables, the snow index, expressed in centimetres here. The legacy Cumulus 1 software reported snow index, calculated from snow depths entered, for all possible periods. Steve Loft had a web page all about it (it was at www.weatherfaqs.org.uk/node/60#SnowIndex), but that server was closed along with his others.

The snow index terminology was invented by the late Philip Eden (14 July 1951 – 3 January 2018), he was a well-known UK meteorologist, who came to Steve's attention via posts in the uk.sci.weather newsgroup. The snow index had extra rules about what to log as your snow depths, so index not distorted by snow drift, or effects of different ground types.

I have never liked technology, but it is difficult to have a life without computers nowadays, so I have taught myself some web page programming, although like you I only dabble at it. Therefore don't take anything I say with more than a pinch of salt, and I'm aware some developers take issue with my approach! Anyway, I have a web page that displays snow indexes in a way that looks just like yours but how I produce it is totally different. Our winters have become so mild recently, that snow is much rarer than when I was a child, meaning analysing snow here nowadays is hardly worthwhile, but I do still (just for me) report snow indexes for each month, season, and year, in the same way I always have.

I like your code for its simplicity. Essentially, you have a web page and the include code you present does multiple tasks, it extracts code from a cumulus file, it calculates month by month figures, and it generates the whole of the table to insert into the web page, including the headings that don't change.

I approached my coding a decade ago from a totally different direction, while on the surface my code is far more complicated, being more modulised it has largely stood the test of time and coped better with external changes not under my control:
1 - My basic system was designed about a decade ago, so for snow was based upon "the log" in the legacy Cumulus 1 which worked differently to the present weather diary, and I merely tweaked that code for MX
2 - I had a public web site when I started, that could not access files on the cumulus computer, so I first experimented with copying file to web server, later I introduced a database server and my web pages access data from that as already described. Now my web site is local, and only for me, I can alter it to read Cumulus files directly, but I don't need to!
3 - I say a modular approach, that means what you do in one piece of code, and a single include into your web page, I have split out:
3 a - obtaining data from cumulus (snow index gets treated differently from rain, from temperature...) (in fact MX changes so rapidly, that I have made almost all changes in last decade just to these modules relating to how data is obtained)
3 b - calculating, my code can sum (or produce a mean of) any data for a month (or other period) (the same code can be used whether adding rainfall amounts, snow depths, or whatever). I also have shared code to find the highest/lowest extreme for the period used whether I am reporting pressure extremes, temperature extremes or whatever. In fact, now I use a database, the column names determine whether sum, mean, highest, lowest, or whatever, shared code is used, so I don't even need to tell my largely automatic running scripts what code to use!
3 c - storing data, my argument has always been what happened last month, or yesterday is normally fixed, so the calculation is done just once, and the result saved (originally in a file, later in a database table) and not done every time I want to display past months (or other period) on a web page. If you use a public server, you want to minimise uploads from your cumulus computer, so only transfer new data, not previously available.
3 d - generic database to row, the same code can read from the stored data (whether it represents snow index or maximum temperature or whatever) and convert it to a row to include on the web page. I can easily alter what appears on a particular web page without redesigning that web page. Also, the web page does not need the code for obtaining data from cumulus, nor the code for calculating (and it is safer not to have that code on any public server)
3 e - headings, the Jan to Dec of your example is fixed, so I have that as part of my web page; in the case of monthly data, I can have a web page that has columns for this month (e.g. October), the monthly-all-time for October (or whichever month) and further columns for October (or whichever month) in past years. The same preceding code modules can be equally used with this second web page

I envy those that can put scripts like that together. Good work!
Me and my numbers mind, other than basic copy and paste, rely on Excel http://www.komokaweather.com/weather/snowfall-log.pdf
and about time to add the 2022-2023 snow season!

I add snow in CMX and C1 daily and in parallel to my CoCoRaHS daily reporting
https://cloud.cocorahs.org/wys/2019-202 ... -2020.html
https://maps.cocorahs.org/?maptype=prec ... 81.4380555

Enjoy,
Paul

Nice @Paul: a kind of 'Missing Link' - report Thanks. More attention for this corner of CMX.

To me it would be interesting to know if it would be worth for CumulusUtils users to have this report native to CUtils i.e. as a user you must register the snow as required to make this report useful. Currently I only see you @Paul, but you have the report and can easily put it in CUtils if needed. Any other user(s)? React below, if its worth the effort I'll make it native but I have my doubts: it's a real niche isn't it. Especially the changes as @sfws indicates.

Thank you @PaulMy and @sfws I appreciate the feedback. It's a work in progress and I'm working at making it more universal for more people to use if they find this useful.

surban21 wrote: ↑Mon 24 Oct 2022 1:19 pm Thank you @PaulMy and @sfws I appreciate the feedback. It's a work in progress and I'm working at making it more universal for more people to use if they find this useful.

@surban21, I have one additional remark: this code assumes it is on the same machine as CMX so it is not useful for a website (in most cases). How do you anticipate its use? Or am I missing something?

@HansR hmmmm oops. See I said I wasn't a programmer. Thanks for pointing that out. Is there something relatively easy that I could include in my code to make website friendly. As I said, I don't have a public website so unable to test that end of it. However, I've learned a lot by doing this.

surban21 wrote: ↑Mon 24 Oct 2022 3:39 pm @HansR hmmmm oops. See I said I wasn't a programmer. Thanks for pointing that out. Is there something relatively easy that I could include in my code to make website friendly. As I said, I don't have a public website so unable to test that end of it. However, I've learned a lot by doing this.

Well, it is some kind of an issue of course as the website does not have access to the CMX machine (technically it could be done but that is not advised). So you will have to find a way to generate the page on the CMX machine and post the presentation to the webserver.

It would be a good idea to check how other templates solve that problem if they do (Saratoga, Weather by You, Weather34, all comprehensive templates but studying code does not hurt).

I can't help you really, I don't do PHP and decided on a totally different solution starting in a roughly similar situation as you are now. But I assume it would imply a separation of the selection of the data and the creation of the presentation.

Anyway, it is already useable for those who have their own webserver on the same machine as CMX so start from there.
Hope this does help a small bit

I see you have added this to your original post:

surban21 wrote: ↑Sun 23 Oct 2022 8:58 pm I have been informed this will only work if you run a website version from your local machine. The same machine that CMX is installed. I am working at making it usable on public website but this will probably take some time to figure out.

You have been informed wrongly, the script you have already written will work for public web sites!

Just tell people who have public web site to use the "Extra Web Files" functionality to copy "diary.db" to their web server once a day. A slight disadvantage to this mechanism is that any updates made to real weather diary after the upload would not be seen by webpage accessing the copy.
However, backup software exists that does a file transfer when a file changes, it is designed for backing up to the cloud, but would be just as suitable for monitoring when the weather diary is updated and then getting a new copy to a public web site.

There are no access worry implications for this, even if a hacker got into the copy, they could not affect the original diary used by MX, nor gain access to any other file/program on Cumulus computer.

Alternative
As an alternative to the above, split the php script you have written into two modules:
- Module A to read the weather diary, and calculate the monthly figures - put into file - this module would have to be run just after any edit to weather diary
- Module B to create a HTML table on a web page, with month headings, and ability to read file and insert figures under headings - this module would appear as an include on web page, so only run when web page is requested. Your module B could be used with other data in future, perhaps your next project?

Obviously there are alternatives to using a file to transfer the data between the two modules, but hopefully minimal further effort from you is needed to add the necessary PHP into Module A to write to a file, and necessary PHP into Module B to read from a file. Anybody using your modules who does not run both on same computer, will have to work out how to run script A after any update to weather diary, and how to then upload the file from cumulus computer to their web server, but that is not your problem.

If you read my earlier post again, I have made it clearer why coding in modules has for past decade worked so flexibly for me. An additional point is that if you code in modules, then you don't include similar code in multiple places, and so if you do make either a mistake or an improvement, there is only one place to edit!

surban21 wrote: ↑Sun 23 Oct 2022 8:58 pm Let me know if this snow table would be useful and worth continuing.

My advice is to split it into two modules just because that could benefit your future coding, you will have learnt about writing to and reading from a file, and gained a module that you could use for other data.

Certainly, don't waste any time trying to make it have a universal appeal, you will never please everyone.

Find another project, your choice, to do next!

Stumped what to choose? Consider thinking about Module A not needing to be run if no edit to weather diary and perhaps work out how to avoid recalculating of past months?

Thank you @sfws for your insight and experience.

I had already started the process of splitting the code into separate modules (php pages) which I think I'm about done doing to a point. I made a webserver html creation module then a data collecting module which I put in the extra web files section of CMX to upload at my set website update interval. This worked well until I realized it was still making a call to my db on the local machine. So now I'm figuring a way for my data collecting module to store the results and to upload the results so the website module can grab the variable and insert them.

You made several good points and found I was sort of on the right path. I realize this fits a small niche of people but for those of us like me I wanted to have something like this and thought I'd share if people found it useful or just pretty to look at. This has been a fun AND trying project which keeps getting more complicated but most of that is due to my ignorance between the difference running it locally and publicly.

That being said, I'm continuing to move forward and WHEN I eventually get something working I will post it for others. I find it difficult at times since I can't test it on a public site but nonetheless I will overcome. Glad to hear that if people wanted to upload their db they can do so and that it would work. And glad to know that if someone was running on local server the same is true. I know the diary.db probably wouldn't ever become very largein size but it would be better to just upload the data instead.

Thank you again and for the inspiration to keep working on this project.

Steve

Finally worked out a way to break the original php file into 2 separate php moduals. One collects the data from diary.db then creates a text file storing the data into arrays. This text file is uploaded to website where the other module pulls the data from the text file and displays the resulting web page. The zip file can be downloaded from the first post of this thread if anyone is interested. This is a continuing project.

Files have been updated to ver 0.4. on 01-04-2023 and includes a few additional items. Works well from what I can test and I will continue to improve the code AS I continue to improve. If anybody is interested the zip can be downloaded from the first post of this thread. This is a continuing project. Thanks

Hi,
Wow, that looks great. I am a little busy at the moment on a couple of other things but will look at and install in the next few days.

Enjoy,
Paul

Thanks Paul, I agree I think it looks pretty nice but I admit the code is a bit rookie-ish. There's a couple sections giving me fits but I'll eventually work through them and simplify the code. In the meantime, It seems to work well (at least on my end) and wanted to get this pushed out.

Steve

Hi,
Took some time and got along ok until I got to the External Programs settings.
I currently use the CumulusMX Internet Settings > External Program settings > Interval and Daily programs for CUtils but that is from within CumulusMX i.e. \CumulusMX\utils\bin\cumulusutils.exe with parameter "website" and "UserAskedData"

I don't know what I would put in for C:\xamp\php\php-win.exe as I don't think I have a local PHP. I am hoping to use it on my website and have PHP with my web service provider, GoDaddy.

p.s. a typo in the How to install...
3rd paragraph... Open snowSummaryData.php in a text editor... should likely be snowSumData.php

Enjoy,
Paul