Ever curious as I am , any light to be shed on this yet......?But I do have something else in progress in the background.
Welcome to the Cumulus Support forum.
Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024
Cumulus MX V4 beta test release 4.0.0 (build 4019) - 03 April 2024
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
Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024
Cumulus MX V4 beta test release 4.0.0 (build 4019) - 03 April 2024
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
Possible future Cumulus direction
Possible future Cumulus direction
- steve
- Cumulus Author
- Posts: 26701
- Joined: Mon 02 Jun 2008 6:49 pm
- Weather Station: None
- Operating System: None
- Location: Vienne, France
- Contact:
Re: Possible future Cumulus direction
I'm slightly reluctant to reply, as progress is slow, and nothing may come of it.
I'm experimenting with a C#/.NET rewrite of Cumulus which is compatible with mono. There are a number of reasons for this approach; firstly, I'm not happy with the direction that Delphi (the development environment I use for Cumulus) is taking. Many other Delphi developers feel the same way. Secondly, I'd like to make a cross-platform version of Cumulus, and mono runs on a large number of platforms: http://www.mono-project.com/Supported_Platforms. Specifically, I'm most interested in getting Cumulus to run on a Raspberry Pi and on Mac OS X (in addition to Windows).
With any cross-platform application, the question of the GUI arises. I have a cunning but possibly madcap idea for this. As was the case with Cumulus 2, the main application will have no GUI (other than a very simple "day one" configuration screen). It will instead operate as a web server, and the GUI itself will be an HTML 5 + Javascript application which will run in a browser. So as well as the 'engine' being cross-platform, the GUI will be cross-platform. The graphs will probably be Highcharts; any gauges would possibly be Mark's SteelSeries gauges. But the point is that the GUI will be open source, so can be modified to appear any way you choose, and there will be a documented interface for reading data from Cumulus, so anyone with the appropriate skills could write their own GUI from scratch (for a tablet or mobile device, for example).
Because I can't possibly start completely from scratch, I am re-using code from Cumulus 2 (which is already C#/.NET) and from Cumulus 1 (by semi-automatically translating it) and it will be file-compatible with Cumulus 1 (i.e. it will read and write the same log files which Cumulus 1 uses). It is likely that I will at some point add an option to also log the data to a local SQL database (probably SQLite) and to a remote SQL database (probably MySQL).
So that's my thinking. If anyone has any comments or suggestions, or can see any problems with this approach, please speak up. I realise that there's an issue with the continuation of 'simple' HTML web sites like the standard site supplied with Cumulus, as the 'engine' would be responsible for generating and uploading web pages etc, and the engine has no graph capability (they are generated in the browser). But I have some thoughts on how this might be solved.
Note that initially this version would not offer any new facilities beyond Cumulus 1 (other than what I've mentioned above) and during an 'alpha' testing phase would have less facilities than Cumulus 1. But it could then be developed, and it will hopefully be easier to add new facilities to this hypothetical future version than it currently is with Cumulus 1.
I'm experimenting with a C#/.NET rewrite of Cumulus which is compatible with mono. There are a number of reasons for this approach; firstly, I'm not happy with the direction that Delphi (the development environment I use for Cumulus) is taking. Many other Delphi developers feel the same way. Secondly, I'd like to make a cross-platform version of Cumulus, and mono runs on a large number of platforms: http://www.mono-project.com/Supported_Platforms. Specifically, I'm most interested in getting Cumulus to run on a Raspberry Pi and on Mac OS X (in addition to Windows).
With any cross-platform application, the question of the GUI arises. I have a cunning but possibly madcap idea for this. As was the case with Cumulus 2, the main application will have no GUI (other than a very simple "day one" configuration screen). It will instead operate as a web server, and the GUI itself will be an HTML 5 + Javascript application which will run in a browser. So as well as the 'engine' being cross-platform, the GUI will be cross-platform. The graphs will probably be Highcharts; any gauges would possibly be Mark's SteelSeries gauges. But the point is that the GUI will be open source, so can be modified to appear any way you choose, and there will be a documented interface for reading data from Cumulus, so anyone with the appropriate skills could write their own GUI from scratch (for a tablet or mobile device, for example).
Because I can't possibly start completely from scratch, I am re-using code from Cumulus 2 (which is already C#/.NET) and from Cumulus 1 (by semi-automatically translating it) and it will be file-compatible with Cumulus 1 (i.e. it will read and write the same log files which Cumulus 1 uses). It is likely that I will at some point add an option to also log the data to a local SQL database (probably SQLite) and to a remote SQL database (probably MySQL).
So that's my thinking. If anyone has any comments or suggestions, or can see any problems with this approach, please speak up. I realise that there's an issue with the continuation of 'simple' HTML web sites like the standard site supplied with Cumulus, as the 'engine' would be responsible for generating and uploading web pages etc, and the engine has no graph capability (they are generated in the browser). But I have some thoughts on how this might be solved.
Note that initially this version would not offer any new facilities beyond Cumulus 1 (other than what I've mentioned above) and during an 'alpha' testing phase would have less facilities than Cumulus 1. But it could then be developed, and it will hopefully be easier to add new facilities to this hypothetical future version than it currently is with Cumulus 1.
Steve
-
- Posts: 317
- Joined: Sat 05 Feb 2011 7:13 pm
- Weather Station: VP2
- Operating System: Windows - all flavours
- Location: Littleport, East Cambs, UK
Re: Possible future Cumulus direction
FWIW, I think this is an excellent strategic approach - perhaps partly because I'd come to exactly the same decision. Other comments might be:
While I can see the appeal of .Net+Mono, I'd seriously wonder whether Python might not be a better long-term option. It's essentially cross-platform out of the box, rather than use the kludge that Mono involves, and very probably will give substantially more compact and less CPU-intensive code, perhaps more suitable for running on small front-ends like the RPi.
I think the database side of it needs doing as formally as possible, eg perhaps SQLite (though I do also wonder about a NoSQL database), and especially with an eye to being able to synchronise any local database with a super-set database on a server or cloud platform.
You might want to think about creating a larger project, eg with more formal buy-in from project-members willing to manage development of the GUI, serverside databases etc.
While I can see the appeal of .Net+Mono, I'd seriously wonder whether Python might not be a better long-term option. It's essentially cross-platform out of the box, rather than use the kludge that Mono involves, and very probably will give substantially more compact and less CPU-intensive code, perhaps more suitable for running on small front-ends like the RPi.
I think the database side of it needs doing as formally as possible, eg perhaps SQLite (though I do also wonder about a NoSQL database), and especially with an eye to being able to synchronise any local database with a super-set database on a server or cloud platform.
You might want to think about creating a larger project, eg with more formal buy-in from project-members willing to manage development of the GUI, serverside databases etc.
- mcrossley
- Posts: 12766
- Joined: Thu 07 Jan 2010 9:44 pm
- Weather Station: Davis VP2/WLL
- Operating System: Bullseye Lite rPi
- Location: Wilmslow, Cheshire, UK
- Contact:
Re: Possible future Cumulus direction
I agree, the strategy is sound for me. Like John I do wonder about Mono, and Python does sound attractive, but ultimately that is down to what you are comfortable with. Farming out 'extra' front ends as community projects would be a good idea to.
This would be my dream solution: Cumulus backend running on a headless RPi, feeding a database, and the Pi also hosting the web server - I think it has more than enough umph to cope with that sort of load, given no GUI desktop etc. would be running.
This would be my dream solution: Cumulus backend running on a headless RPi, feeding a database, and the Pi also hosting the web server - I think it has more than enough umph to cope with that sort of load, given no GUI desktop etc. would be running.
- steve
- Cumulus Author
- Posts: 26701
- Joined: Mon 02 Jun 2008 6:49 pm
- Weather Station: None
- Operating System: None
- Location: Vienne, France
- Contact:
Re: Possible future Cumulus direction
I don't want this to become a 'language war', but while I detest C and C++, I like C# a lot, and find Visual Studio very good to work with. I don't regard Mono as a 'kludge' at all, and all the benchmarks I've seen suggest that Mono is much more efficient than Python. And I have a lot of Cumulus code in C# already (from Cumulus 2).prodata wrote:While I can see the appeal of .Net+Mono, I'd seriously wonder whether Python might not be a better long-term option. It's essentially cross-platform out of the box, rather than use the kludge that Mono involves, and very probably will give substantially more compact and less CPU-intensive code, perhaps more suitable for running on small front-ends like the RPi.
Steve
-
- Posts: 317
- Joined: Sat 05 Feb 2011 7:13 pm
- Weather Station: VP2
- Operating System: Windows - all flavours
- Location: Littleport, East Cambs, UK
Re: Possible future Cumulus direction
Wasn't intended to be a sideswipe at .Net - for my sins, all I can comfortably use is VB2012! So I'm firmly in the .Net camp currently for Windows apps.steve wrote:I don't want this to become a 'language war'...
But it does worry me somewhat that Mono is presumably some sort of reverse-engineered version of the .Net framework and so - presumably again - has all sorts of unpredictable potential for particular .Net functions not working exactly as expected (and sometimes maybe not at all) on 'foreign' platforms. But it's certainly not my field of expertise and I'm happy to have my prejudice proved wrong. (Although I'd still be somewhat surprised, knowing how large and complex the .Net framework has become, to see a surrogate in the form of Mono perform well for complex applications on relatively limited hardware like the RPi. But very possibly I'm just out of touch with what the Mono community has been able to achieve?)
- steve
- Cumulus Author
- Posts: 26701
- Joined: Mon 02 Jun 2008 6:49 pm
- Weather Station: None
- Operating System: None
- Location: Vienne, France
- Contact:
Re: Possible future Cumulus direction
Mono isn't reverse engineered, it's written to the published ECMA/ISO .NET CLI standards and documentation from Microsoft. Microsoft co-operated with Novell in the development of Mono.
Steve
-
- Posts: 1256
- Joined: Mon 09 Jul 2012 8:40 pm
- Weather Station: Davis VP2 Cabled
- Operating System: Windows 10 Pro
- Location: Auckland, New Zealand
- Contact:
Re: Possible future Cumulus direction
Looks like a great strategy Steve - all power to you!
Please ensure any SQL flavour chosen is one commonly supported by web hosters as this will reduce the hassles end users will find with minor syntax and other differences between flavours.
MySQL appears to be very common on most hosters (and the only one on many lower cost services) and is a part of most Apache distributions so I feel that is a good choice.
I know many like alternative packages for various reasons but as a long term user and supporter of others in the computing environment I hate to think how many times I (and my clients) have been caught out by the use of that 'better' system. Following the most 'standard' (not the current most popular!) route has always worked best for me and my clients in the long run.
Please ensure any SQL flavour chosen is one commonly supported by web hosters as this will reduce the hassles end users will find with minor syntax and other differences between flavours.
MySQL appears to be very common on most hosters (and the only one on many lower cost services) and is a part of most Apache distributions so I feel that is a good choice.
I know many like alternative packages for various reasons but as a long term user and supporter of others in the computing environment I hate to think how many times I (and my clients) have been caught out by the use of that 'better' system. Following the most 'standard' (not the current most popular!) route has always worked best for me and my clients in the long run.
-
- Posts: 505
- Joined: Wed 17 Aug 2011 2:58 pm
- Weather Station: WeatherDuino Pro2
- Operating System: 2008
- Location: Canberra
Re: Possible future Cumulus direction
This sounds like a good plan going forward.
I'm more than willing to be a tester when necessary.
Steve, I wouldn't mind if the software was supplied on a license with a (smallish) fee instead of the current arrangement.
I'm more than willing to be a tester when necessary.
Steve, I wouldn't mind if the software was supplied on a license with a (smallish) fee instead of the current arrangement.
Interested in building your own Weather Station? Maybe check out the WeatherDuino Pro Project Here
Conder, Canberra Weather
Conder, Canberra Weather
Re: Possible future Cumulus direction
I agree with Bob and have read the suggestion of 'shareware' else where in the forum. I think a license would/could be a good way forward to evolve Cumulus.uncle_bob wrote: Steve, I wouldn't mind if the software was supplied on a license with a (smallish) fee instead of the current arrangement.
-
- Posts: 365
- Joined: Wed 07 Jan 2009 10:36 pm
- Weather Station: wh1081
- Operating System: windows 10
- Location: Oban Scotland
Re: Possible future Cumulus direction
you can add me onto the list for testing as well and agree with the comments about shareware.
I must admit I did like cumulus 2 but understand why you put it on hold.
good look with this version
I must admit I did like cumulus 2 but understand why you put it on hold.
good look with this version
- steve
- Cumulus Author
- Posts: 26701
- Joined: Mon 02 Jun 2008 6:49 pm
- Weather Station: None
- Operating System: None
- Location: Vienne, France
- Contact:
Re: Possible future Cumulus direction
Yes; even though I have issues with Oracle as a company, I accept that MySQL dominates the market, so any remote database functionality would have to support that, but without using the Oracle client connector. I've found a reasonably-priced .NET MySQL connector which has no 'per site' licence requirements, and it works with Mono, so that looks promising.BCJKiwi wrote:Please ensure any SQL flavour chosen is one commonly supported by web hosters as this will reduce the hassles end users will find with minor syntax and other differences between flavours.
MySQL appears to be very common on most hosters (and the only one on many lower cost services) and is a part of most Apache distributions so I feel that is a good choice.
Steve
- mcrossley
- Posts: 12766
- Joined: Thu 07 Jan 2010 9:44 pm
- Weather Station: Davis VP2/WLL
- Operating System: Bullseye Lite rPi
- Location: Wilmslow, Cheshire, UK
- Contact:
Re: Possible future Cumulus direction
Hmm, now what would a good the perfect weather database schema look like?
- steve
- Cumulus Author
- Posts: 26701
- Joined: Mon 02 Jun 2008 6:49 pm
- Weather Station: None
- Operating System: None
- Location: Vienne, France
- Contact:
Re: Possible future Cumulus direction
Yes, indeed, and this is where I am hoping to get advice from those that know more than I do about this. I created the one in Cumulus 2 based on the Weatherlink file structure, and initially it only had one table. I'm sure it could be done better.mcrossley wrote:Hmm, now what would a good the perfect weather database schema look like?
Steve
- mcrossley
- Posts: 12766
- Joined: Thu 07 Jan 2010 9:44 pm
- Weather Station: Davis VP2/WLL
- Operating System: Bullseye Lite rPi
- Location: Wilmslow, Cheshire, UK
- Contact:
Re: Possible future Cumulus direction
OK, I have a dev Pi ready and waiting Steve!
A clean Debian build loaded up with Apache2, PHP, vsftpd, MySQL and lots of other bits and pieces. I copied across my live SQL database a PHP/SQL query and index page to see how it coped - pretty good so far I think bearing in mind it is also running on a WiFi link in house as well as being on ADSL at the mo.
A clean Debian build loaded up with Apache2, PHP, vsftpd, MySQL and lots of other bits and pieces. I copied across my live SQL database a PHP/SQL query and index page to see how it coped - pretty good so far I think bearing in mind it is also running on a WiFi link in house as well as being on ADSL at the mo.