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
From build 3044 the development baton passed to Mark Crossley. Mark has been responsible for all the Builds since. He has made the code available on GitHub. It is Mark's hope that others will join in this development, but at the very least he welcomes your ideas for future developments (see Cumulus MX Development suggestions).
freddie wrote: ↑Sat 13 Jan 2024 8:54 pm
I'm not in favour of any control over what can be set as the context is unpredictable, therefore it is impossible to formulate sensible rules that can be applied.
Control is one thing, guidance another.
And it is not impossible, heuristics can be formulated.
freddie wrote: ↑Sat 13 Jan 2024 8:54 pm
All of my readings (and some derived ones) are updated at a two second realtime interval, and my system copes fine with that cadence.
This depends also on the hardware you are using. And afaiac : a 2 second interval is kind of over the top from a CMX weather point of view. There is no realtime in CMX/websites. There never will be. if CMX would forbid any realtime interval smaller than 10 seconds I could live with that.
freddie wrote: ↑Sat 13 Jan 2024 8:54 pm
I'm not in favour of any control over what can be set as the context is unpredictable, therefore it is impossible to formulate sensible rules that can be applied.
Control is one thing, guidance another.
And it is not impossible, heuristics can be formulated.
freddie wrote: ↑Sat 13 Jan 2024 8:54 pm
All of my readings (and some derived ones) are updated at a two second realtime interval, and my system copes fine with that cadence.
This depends also on the hardware you are using. And afaiac : a 2 second interval is kind of over the top from a CMX weather point of view. There is no realtime in CMX/websites. There never will be. if CMX would forbid any realtime interval smaller than 10 seconds I could live with that.
Guidance is fine - yet you use terms such as forbid and prevent in the above quotes.
You are correct in that there is no true realtime in MX - but there is no harm in approximating it as closely as possible. Davis stations perform 2.5 second updates - that is why I chose a 2 second realtime interval. I don't see it as over the top, but that is my opinion. If I had a station that would perform 1 second updates then that is what I would set my interval to. The reverse is true too - if my Davis station was replaced by a station that did 10 second updates then I would set my realtime interval to 10 seconds. It's about recording the maximum data possible from your station, and getting the most benefit from your update interval.
Meteorological parameters (especially wind) can vary over very small time intervals, and it is my objective to capture and display as much of that variation as possible.
freddie wrote: ↑Sat 13 Jan 2024 10:05 pm
Meteorological parameters (especially wind) can vary over very small time intervals, and it is my objective to capture and display as much of that variation as possible.
Wind is presented as average in CMX, not as the realtime value so no need to send the value at high frequency.
High frequency uploads is fooling yourself.
Anyway, arguments about uses or not of rapid updates (the Dashboard wind values/gauges update once a second if you have an Instromet station). Coding in warnings and prohibitions would mean adding a fair bit logic to cope with "known" files (those generated by MX) and would be useless for all others, and the "others" tend to be those for which Extra Files is most used.
So, I do not intend to make any change, my time and effort is best spent elsewhere.
Real time interval is now 10 seconds.
I adjusted the extra web files as you indicated and all works fine!
About your aother remarks:
Are you also uploading files using the standard upload settings? I'm just wondering why moon.png, realtime.txt, realtimegauges.txt, websitedata.json are being uploaded via Extra Files? I am doing this because my remote ftp directory is set to wwwroot/Cumulus/ .
In this way I can upload to 2 websites the deafult one and the Cumulus one, is there a way to upload to multiple sites?
Because of my provider restrictions, I can't use the php upload, my provider doesn't allow to change files within a site.
that's why also the Cutils doesn't work by means of the cumulusrealtimelocation feture.
Also, if you created symbolic file links on the destination server for the files you are uploading multiple times, could you just upload them once?
don't know what you mean by this. Can you give me helping hand?
alexvanuxem wrote: ↑Sun 14 Jan 2024 11:03 am
I can't use the php upload, my provider doesn't allow to change files within a site.
Strange.
alexvanuxem wrote: ↑Sun 14 Jan 2024 11:03 am
that's why also the Cutils doesn't work by means of the cumulusrealtimelocation feture.
The cumulusrealtimelocation does not change any file, it just points to another location where CMX uploads the realtime and data files.
And btw... CUtils can use any upload technique CMX uses, it uses the settings it finds in Cumulus.ini.
Hi,
Your MXUIwebsite is looking good.
I do notice some data missing in prior years - i.e. May 2023. If you have the monthly log files that have data for those days then you can run CreateMissing utility to fill on that missing data .
mcrossley wrote: ↑Sat 13 Jan 2024 7:49 pm
MX has no idea what the files contain or what they will be used for.
And there was me thinking people would leave the standard files alone and create ones with different names for personal uses. Silly me
As for upload frequency, rather than have us arguing about what a warning vs prohibition policy might be, surely the better programmatic approach would be "If the previous upload hasn't finished, don't try to start another one"? That's a coding one-liner!
Whilst it might be a simple change, the outcome of doing that would still be identical in this case. The website wouldn't have updated properly, so there would have been a question about why that was happening, with the eventual realisation that there were too many files being updated much too quickly.
Last edited by packman2008 on Mon 15 Jan 2024 8:13 am, edited 1 time in total.
Cortmalaw wrote: ↑Sun 14 Jan 2024 11:01 pm
And there was me thinking people would leave the standard files alone and create ones with different names for personal uses. Silly me
Not sure what you are getting at here?
Cortmalaw wrote: ↑Sun 14 Jan 2024 11:01 pm
As for upload frequency, rather than have us arguing about what a warning vs prohibition policy might be, surely the better programmatic approach would be "If the previous upload hasn't finished, don't try to start another one"? That's a coding one-liner!
Hmm interesting. After having another go at applying the latest update all appears to have gone smoothly this time around.
That said, I did give the Winblows (oh, did I say that I meant Windows) a bit of TLC, sfc found a few things and fixed them it told me.
All appears well.
Again, thanks to the genius of Mark at making such a wonderful, useful, magnificent software.
