So I sat back for a while looking around for new ideas and testing some things out for ideas I already had.
The ideas were:
- Get SFTP implemented
- Get MySQL as a legitimate datasource for CumulusUtils. Currently only the logfiles can be used but with long dataseries the monthly logfiles become a serious performance bottleneck. Hoping MySQL could give some relief there.
- The static graphs which originally came with CMX are increasingly challenged by users with additional graphing questions. I am beginning to address that issue.
2) I began doing some research on the use of MySQL/MariaDB as a possible data source for CumulusUtils. The current status of the use of the database is not self evident because of performance issues (fill the database must be as fast as possible) and the concept of CumulusUtils which does not accept daily datafile transfer to the website and use some PHP procedure there to keep the database synchronised. Afaiac the database must have the same integrity properties as the logfiles, I made already a request for that but no doubt - if ever - that will take some time. So we'll see where this goes.
3) One of the developments which excite me most is the slow abandonment of the static/rigid charting/graphing of the data in the database (I use this term now for both logfile and MySQL, so it is in a more abstract meaning). Currently there is the cumuluscharts and recently Mark moved a bit with the great Select-a-Chart function, added to both the management interface as the standard website. The procedure has been included by several templates as well.
So should I do that or should I take my different approach?
I had already been thinking about this issue and decided to follow that path and not include the Select-a-Chart .
My way is slightly different, because it must fit within the CumulusUtils concept which basically is defining modules and a website. For the time being my concept will only be available from within the website, not as a separate module. To make the charts user definable, I am working on a Chart compiler. This means the user can define multiple charts in a kind of natural language for any kind of combination of data (e.g. like dew point with pressure) as follows:
Code: Select all
Chart Temperature Title Temperature Inclusive Inside
PLOT Temperature As spLine Colour Blue zIndex 90
PLOT FeelsLike As Line Colour Red zIndex 80
PLOT DewPoint As Line Colour yellow zIndex 70
PLOT ApparentTemp As Line Colour grey zIndex 60
PLOT WindChill As Line Colour cyan zIndex 50
PLOT HeatIndex As Line Colour pink zIndex 40
PLOT Humidex
EndCHART
Chart Pressure Title Sealevel Pressure
PLOT pressure As spLine Colour green zIndex 90
EndCHART
Chart Rain Title Rain and RainRate
PLOT RainFall As Area Colour green zIndex 10
PLOT RainRate As spline Colour blue zIndex 90
EndCHART
Chart Wind Title All Winds
Plot WindGust As spLine
Plot WindSpeed As spline
EndChart
Chart Solar Title (Max)Radiation and UV
Plot UV Colour blue zindex 100
Plot SolarRadiation Colour Orange zIndex 50
Plot TheoreticalSolarMax Colour Gold zIndex 10
EndChart
But there are some technical hickups to overcome which slow development down a bit apart from the natural time it takes as it is quite a major task. Anyway, nice work for a lockdown with curfew but still it is a major thing to to. And then I am only talking about the data which are already available through the current CMX JSON files. It is not clear to me what data may become available in future but I already have an engine to create my own required data JSONs so it would be possible to expand that and make all data available which would be required for what the user wants. AllData series is not my primary view on things because for longer data series that will become an issue unless there would be direct access from the website to the Cumulus Machine which I think is unwise (and I am not alone).
Only restriction: this will never be done on the fly for the visitor of the website. Just like language it will be a compile time feature supplying a website which the user wants to display to its visitors. It will not be a visitor feature.
So that is the status. If the SFTP goes well there will be a 4.10.6 release and then there will be silence for some time I guess.
Comments and suggestions, as always are welcome.
NOTE: The Chart compiler is triggered by the presence of a CutilsCharts.def file in the utils directory (case dependent in LInux). It will already do something so you can play but don't expect anything. There is so far no commandline parameter associated with the compiler and the connection with the gauges is lost (all will be taken care of of course). If you make errors in the language you can read the error messages in the logfile (near the end while creating cumuluscharts).
NOTE: the word after chart is what you will see in the drop down menu; the word after plot is a keyword which translates into the variable in the json I will give you the keywords below, otherwise you will never see anything.
Keywords for the Plot variable (these should be self evident):
"InsideTemp", "Dewpoint", "ApparentTemp", "FeelsLike", "WindChill", "HeatIndex", "Temperature", "Humidex",
"WindGust", "WindSpeed",
"Bearing", "AverageBearing",
"UV", "SolarRadiation", "TheoreticalSolarMax",
"RainFall", "RainRate",
"Pressure",
"Humidity", "InsideHumidity",
"MinimumTemp", "MaximumTemp", "AverageTemp",
"Dailyrain",
"Sunhours"