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
CMX crash and realtime retain failure
Moderator: mcrossley
- mcrossley
- Posts: 12756
- Joined: Thu 07 Jan 2010 9:44 pm
- Weather Station: Davis VP2/WLL
- Operating System: Bullseye Lite rPi
- Location: Wilmslow, Cheshire, UK
- Contact:
Re: CMX crash and realtime retain failure
Well, that's not right at all!
Something has obviously gone wrong at some point. I'm reworking the MySQL stuff at the moment, so I'll take a look at getting it fixed tomorrow...
Something has obviously gone wrong at some point. I'm reworking the MySQL stuff at the moment, so I'll take a look at getting it fixed tomorrow...
- mcrossley
- Posts: 12756
- Joined: Thu 07 Jan 2010 9:44 pm
- Weather Station: Davis VP2/WLL
- Operating System: Bullseye Lite rPi
- Location: Wilmslow, Cheshire, UK
- Contact:
Re: CMX crash and realtime retain failure
Hang on, the problem is purely in the help text. You should just try entering the text as "value unit". So for example "10 DAY"
See: https://dev.mysql.com/doc/refman/8.0/en ... -intervals
See: https://dev.mysql.com/doc/refman/8.0/en ... -intervals
- HansR
- Posts: 5957
- Joined: Sat 20 Oct 2012 6:53 am
- Weather Station: GW1100 (WS80/WH40)
- Operating System: Raspberry OS/Bookworm
- Location: Wagenborgen (NL)
- Contact:
Re: CMX crash and realtime retain failure
Indeed. Fooled by the help text. Room for improvement here.
Thanks!
I suggest to give just the number (of days) and have days implicit. Nobody is going to retain more than a month of realtime unless you would want stress the limits of your database. And even then, you could give a 1000 days, 10.000 or whatever (would that be possible?). No formatting of (partial) SQL statements must be left to the user. Users are not programmers, they are users. CMX is being/becoming too much a programmers program iso of a meteo program.
Thanks!
I suggest to give just the number (of days) and have days implicit. Nobody is going to retain more than a month of realtime unless you would want stress the limits of your database. And even then, you could give a 1000 days, 10.000 or whatever (would that be possible?). No formatting of (partial) SQL statements must be left to the user. Users are not programmers, they are users. CMX is being/becoming too much a programmers program iso of a meteo program.
Hans
https://meteo-wagenborgen.nl
CMX build 4017+ ● RPi 3B+ ● Raspbian Linux 6.1.21-v7+ armv7l ● dotnet 8.0.3
https://meteo-wagenborgen.nl
CMX build 4017+ ● RPi 3B+ ● Raspbian Linux 6.1.21-v7+ armv7l ● dotnet 8.0.3
- mcrossley
- Posts: 12756
- Joined: Thu 07 Jan 2010 9:44 pm
- Weather Station: Davis VP2/WLL
- Operating System: Bullseye Lite rPi
- Location: Wilmslow, Cheshire, UK
- Contact:
Re: CMX crash and realtime retain failure
The problem is migration. People will already have configured that setting previously and may have 2 WEEK or 1 MONTH set for instance
I think you may be surprised how much real time data some people are retaining!
I'm not sure I agree with that statement. I have been trying to simplify the settings screens by removing irrelevant settings, and removing the need for users to edit Cumulus.ini to alter settings, so I would argue the opposite case.
I think you may be surprised how much real time data some people are retaining!
Yes, with hindsight it may have been better to to have a number of days field, but that isn't what was set up originally by Steve years ago.Users are not programmers, they are users. CMX is being/becoming too much a programmers program iso of a meteo program.
I'm not sure I agree with that statement. I have been trying to simplify the settings screens by removing irrelevant settings, and removing the need for users to edit Cumulus.ini to alter settings, so I would argue the opposite case.
-
- Posts: 2473
- Joined: Wed 08 Jun 2011 11:19 am
- Weather Station: Davis Vantage Pro 2 + Ecowitt
- Operating System: GNU/Linux Ubuntu 22.04 LXC
- Location: Alcaston, Shropshire, UK
- Contact:
Re: CMX crash and realtime retain failure
I would argue the opposite case too - you have done a lot of work to make settings user-oriented.mcrossley wrote: ↑Mon 12 Apr 2021 8:55 am The problem is migration. People will already have configured that setting previously and may have 2 WEEK or 1 MONTH set for instance
I think you may be surprised how much real time data some people are retaining!
Yes, with hindsight it may have been better to to have a number of days field, but that isn't what was set up originally by Steve years ago.Users are not programmers, they are users. CMX is being/becoming too much a programmers program iso of a meteo program.
I'm not sure I agree with that statement. I have been trying to simplify the settings screens by removing irrelevant settings, and removing the need for users to edit Cumulus.ini to alter settings, so I would argue the opposite case.
Regarding the setting in question - how about a drop-down menu with some choices, with the translation to the SQL equivalent as the submitted values?
- mcrossley
- Posts: 12756
- Joined: Thu 07 Jan 2010 9:44 pm
- Weather Station: Davis VP2/WLL
- Operating System: Bullseye Lite rPi
- Location: Wilmslow, Cheshire, UK
- Contact:
Re: CMX crash and realtime retain failure
How about...
You do not have the required permissions to view the files attached to this post.
- HansR
- Posts: 5957
- Joined: Sat 20 Oct 2012 6:53 am
- Weather Station: GW1100 (WS80/WH40)
- Operating System: Raspberry OS/Bookworm
- Location: Wagenborgen (NL)
- Contact:
Re: CMX crash and realtime retain failure
@mcrossley, @freddie:
Anyway, further irrelevant probably, so just take it as a loose remark
EDIT: Trying to post this reply I saw your solution. Seems great to me.
Btw: those fields are always below each other, is it possible to have them beside each other?
Any numbers and a reason why?
OK. Maybe freddie's suggestion may help here. I could live with that.mcrossley wrote: ↑Mon 12 Apr 2021 8:55 amYes, with hindsight it may have been better to to have a number of days field, but that isn't what was set up originally by Steve years ago.Users are not programmers, they are users. CMX is being/becoming too much a programmers program iso of a meteo program.
I see what you have done with the settings and I think that is a great action (like so many other actions). My remark comes not so much from this specific setting as well as from the fact that all other SQL is actually left to the user. The user is invited (at least not discouraged) to modify all kinds of code around - and within - CMX creating issues of its own (is there a repository of SQL queries in use?).
Anyway, further irrelevant probably, so just take it as a loose remark
EDIT: Trying to post this reply I saw your solution. Seems great to me.
Btw: those fields are always below each other, is it possible to have them beside each other?
Hans
https://meteo-wagenborgen.nl
CMX build 4017+ ● RPi 3B+ ● Raspbian Linux 6.1.21-v7+ armv7l ● dotnet 8.0.3
https://meteo-wagenborgen.nl
CMX build 4017+ ● RPi 3B+ ● Raspbian Linux 6.1.21-v7+ armv7l ● dotnet 8.0.3
- mcrossley
- Posts: 12756
- Joined: Thu 07 Jan 2010 9:44 pm
- Weather Station: Davis VP2/WLL
- Operating System: Bullseye Lite rPi
- Location: Wilmslow, Cheshire, UK
- Contact:
Re: CMX crash and realtime retain failure
Sadly no, there is a layout option for side-by-side, but it is an all or nothing option, it has to apply to the whole page. I have made a request that it be supported on a sub section basis, as have other people, but no response
- mcrossley
- Posts: 12756
- Joined: Thu 07 Jan 2010 9:44 pm
- Weather Station: Davis VP2/WLL
- Operating System: Bullseye Lite rPi
- Location: Wilmslow, Cheshire, UK
- Contact:
Re: CMX crash and realtime retain failure
Originally because the MySQL is not something Cumulus MX is "interested" in, like MQTT etc is is something that it can provide data for, but has no interest in reading back. If MX used it as a storage resource then yes it should a fixed schema to ensure compatibility.HansR wrote: ↑Mon 12 Apr 2021 10:00 am My remark comes not so much from this specific setting as well as from the fact that all other SQL is actually left to the user. The user is invited (at least not discouraged) to modify all kinds of code around - and within - CMX creating issues of its own (is there a repository of SQL queries in use?).
MX provides a suggested schema, which probably the vast majority of SQL users will use and that is fine.
But if people want to freewheel they can - I do, I store additional data that is of interest and useful to me. I have also added triggers, stored procedures and additional tables to drive my web site. I guess my view is if you are competent enough to stray away from the default you are knowledgeable enough to sort out any consequences, or live with them
For me its a balance, you are proscriptive with settings and reduce flexibility, or allow have defaults but allow customisation and increase flexibility.
- HansR
- Posts: 5957
- Joined: Sat 20 Oct 2012 6:53 am
- Weather Station: GW1100 (WS80/WH40)
- Operating System: Raspberry OS/Bookworm
- Location: Wagenborgen (NL)
- Contact:
Re: CMX crash and realtime retain failure
Yes. And that is great and good. My own coding started out there as well. No problem.
But let's be honest: there is e.g. a lot of code which apparently is based on SQL (PHP procedures with implicit SQL) and there is a lot of variability in there. I think those queries and that structure could/should become part of Core-CMX. The procedures around it as well. If it were only those things were assembled in some repository (or is it already? I could have missed it) where at least the basis is maintained / stabilised. The same holds for javascript.
It's the divergence which disturbs me.
CMX is at the basis and has by definition a lot of divergence because of what you want to serve.
CUtils for a data presentation needs convergence. That is a big difference.
I don't think we differ very much though you bend more to one side I more to the other.
The difference looks big, but the feet are close.
If CMX had not been so limitless (which it isn't), CUtils had not become so limiting (which btw it isn't either).
But anyway, you never know, maybe sometime a nice discussion over a pint or two on applications, how to setup things, users and developers
Hans
https://meteo-wagenborgen.nl
CMX build 4017+ ● RPi 3B+ ● Raspbian Linux 6.1.21-v7+ armv7l ● dotnet 8.0.3
https://meteo-wagenborgen.nl
CMX build 4017+ ● RPi 3B+ ● Raspbian Linux 6.1.21-v7+ armv7l ● dotnet 8.0.3