Cumulus Wiki

MX Administrative Interface: Difference between revisions

Page Discussion

MX Administrative Interface (view source)

Revision as of 06:13, 8 September 2020

7,042 bytes added ,  8 September 2020
m
no edit summary
mNo edit summary
 
 
#Type the URL which is displayed (when MX starts running) into your browser (replace the * with the IP address, or use 'localhost') and the '''admin interface''' should appear. You will be viewing your admin interface on the same network as the the MX engine is using, so what you type might be something like <tt>http://192.168.1.xxy:y/8998</tt> and you may need to look at your hub or router to see what to use for x and y as they represent the device where MX is running.
#*If this is a 'clean' installation, ''i.e. you don't have an existing [[Cumulus.ini]] file defining station type and units to be used'', the first thing you will need to do is to go to the '''settings''' screen.
#When that page is displayed it always shows the options to set the station type and units.
 
*When you select a line, two buttons are enabled:
*#'''Edit''' - rather obviously brings up a dialog (known as modal by the '''altEditor''' software that generates it) a dialog (dataTables calls this a modal) showing all fields and letting you change the contents of most individual fields. Scroll down and in the footer are two buttons:
*##''Save'' will send the edited line back to the MX engine where the log file is then read into an array, and the relevant array element is replaced by the line received. After that the log file is overwritten from the amended array. After that the log file as a whole is converted back to dataTables format and returned by the api that delivered the table originally.
*#'''Close'''. You can close this dialog in 3 ways:
* The api expects the log file to contain all the fields defined in the version of MX that is being used.
*Lines in the log files created by earlier versions of Cumulus (Cumulus 1 or MX) may have fewer fields
*The way that MX has been written is inconsistent in the way it deals with fields that MX now expects but at the time that any log line was created did not exist. When adding the missing fields, some are added with empty string as content and some are added with a single space as content. When the editing modal is opened it willmay display placeholder text where a missing field is empty, but if you don't see that place-holder, there is probably a space included in the supposedly empty field (that you can't see), but maythat wellspace (if not removed) could muck up any number you now want to enterstore there.
*If you do edit a line, and then '''Save''', then that particular line (but no others in the log file) will change its length to that used by the current version of MX and you will see additional trailing field separators (commas, semicolons, or whatever defined for your locale) in that line making it seem different from its neighbours. Again you may spot thatan inconsistency in content as some gaps may appear between delimiters where spaces have been added for fields that were originally missing.
 
== Changing Settings ==
All settings are stored in [[Cumulus.ini]], so when you stop and restart MX, it can continue without you entering settings again.
 
All settings are stored in [[Cumulus.ini]], so when you stop and restart MX, it can continue without you entering settings again.
Adjusting the majority of them is best done using the MX "admin interface" screens, you will see that '''Settings''' is the penultimate option in the navigation bar, and it has a drop down for the various settings screens that are now described. [[File:Settings Menu.png|right]]
 
Adjusting the majority of the settings is best done using these MX "admin interface" screens simply because for some settings the interface does validation (whilst editing the file directly could introduce invalid settings), you will see that '''Settings''' is the penultimate option in the navigation bar, and it has a drop down for the various settings screens that are now described. [[File:Settings Menu.png|right]]
*For most screens a HTML form element is used for editing, its content is determined by one JSON file, the allowed settings are fixed by a second JSON file, and there is a '''Save''' button to send the contents of that form for processing.
For most screens a HTML form element is used, there is a '''Save''' button to send the contents of that form for processing, and that must be clicked (and an acknowledgement displayed that the form processing has completed) before the edited settings are accepted. To make it easy to change settings, such setting screens uses tick boxes, radio buttons, and drop down selection boxes, so the choices available are clearly laid out. These form based MX settings screens do some validation, and if you make an error the contents change to a red colour (red text and red boxes), that means invalid data is present which must be corrected before the form can be sent by pressing '''Save''' button. One or more items on the page will have an error message added by the form processing in those validation fail cases.
*That Save button must be clicked (and an acknowledgement displayed that the form processing has completed) before the edited settings are accepted by MX.
**Note that some settings take immediate effect, some settings are only read when MX starts, so it may be necessary to stop and restart MX to ensure your new settings take effect
*To make it easy to change settings, such setting screens uses tick boxes, radio buttons, and drop down selection boxes, so the choices available are clearly laid out.
*These form based MX settings screens do some validation, and if you make an error detected by the validation, the contents change to a red colour (red text and red boxes), that means invalid data is present which must be corrected before the form can be sent by pressing '''Save''' button.
**Generally, a whole section goes red, not just the item at fault (as determined by JSON file specifying valid options)
**One, or more, items on the page will have an error message added by the form processing in those validation fail cases, indicating porecisely which item(s) need(s) to be corrected.
 
If you attempt to set these settings by directly editing the file where they are stored, there is a danger of either making a typo or of choosing an illegal value for a particular attribute.
 
There are however some '''read only''' settings that can not be found in any of the setting screens, for these MX cannot set the values, it can only read them. As MX cannot set the values, you need to edit the [[Cumulus.ini]] file directly, and the referenced Wiki page givesidentifies details of whichread-only settings that can only be adjusted by adding parameters directly in the file. The configuration article lists the read-write settings as well, and tells you what values are accepted for those attributes, and also explains some of the differences in the settings available between Cumulus 1 and MX.
'''Note that if you change settings''', that '''some''' settings do not take effect while MX is running, while other settings do take effect instantly (IThe havedeveloper has not foundprovided a definitive list anywhere of which settings do, and which do not, take effect immediently, although sometimes a release notice mentions this for a new setting) - anyway, you ''may'' need to restart Cumulus MX to get the new setting picked up. When you exit MX, it saves the read-write settings in [[Cumulus.ini]], and when you restart it it uses the read-only, and read-write, settings it reads from that file.
 
 
(Aside: The "Success" message (with all possible alternatives) is defined in <tt>CumulusMX\interface\lib\datatableseditor\dataTables.altEditor.free.js</tt>, I am unsure whether this is used with the settings pages, but it is possible you can edit that script to make messages like "Success" appear in a different language).
 
=== Station Settings ===
 
Each setting has a hint beside it (with a small 'i' for information before each hint). If you have used [[Cumulus_Screenshots#Station|Cumulus 1]], the layout and section headings will be familiar. No settings taketakes effect until '''Save''' button pressed.
 
Like all the settings pages, thethere are headings arewith collapsedsettings andbelow needthem tothat beare clickedcollapsed so click headings to see the items under them.
 
The table [[Cumulus.ini#Section:_Station|here for the [Station] section]] will explain how MX stores the selections you make here, and give a bit more detail about each item and the values it can take. Please note that, in the '''Options''' section, there are two settings that take effect immediately '''Save''' is pressed, but are not written to '''Cumulus.ini''' and will be reset when MX is restarted; these two exceptions are to use '''Debugging logging''' and to use '''Data Logging'''. The first adds extra output to the log file created in "CumulusMX/MXDiags" folder reporting in detail each output task MX does. The second adds extra output to the log file created in "CumulusMX/MXDiags" folder reporting in detail each input received from the weather station.
 
Please note that, in the '''Options''' section, there are two settings that take effect immediately '''Save''' is pressed, but are not written to '''Cumulus.ini''' when MX is closed, so will be reset when MX is restarted; these two exceptions are to use '''Debugging logging''' and to use '''Data Logging'''. The first adds extra output to the log file created in "CumulusMX/MXDiags" folder reporting in detail each output task MX does. The second adds extra output to the log file created in "CumulusMX/MXDiags" folder reporting in detail each input received from the weather station.
 
==== Station Type ====
 
Select the one that matches your weather station. If you are unsure, look at [[Supported Devices]] article because it explains abouthow alternative brands are mapped to particular generic types.
 
==== Units ====
 
 
One feature of Cumulus is that it does not matter what units the weather station uses, every reading is converted to units you select here, and generally every thing Cumulus does is based on those units. There is one exception, which only affects those in USA; internally Cumulus uses Celsius for more calculations, if you have requested Fahrenheit, it is only used for entries in log files, web tags, and NOAA reports.
Steve Loft designed Cumulus 2, so the units you selected effected how a value was shown, but not how the value was stored. Consequently in Cumulus 2, you could change units at any time easily.
 
Cumulus 3 (MX) reverts to the approach used by Cumulus 1, the units you choose in the settings determine how values are stored, therefore you choose units when you first start MX and don't change them again (unless you are prepared to edit all the existing values in log files, including all the extreme records).
 
So for Cumulus MX, it does not matter what units the weather station uses, every reading is converted to units you select here, and generally every thing Cumulus does is based on those units. There is one exception, which only affects those users in USA; internally Cumulus uses Celsius for most calculations, if you have requested Fahrenheit, MX does a conversion from its internal values when writing entries in log files, web tags, and NOAA reports; that means if the weather station outputs in Fahrenheit, there is one conversion on reading the station, and a second conversion on output.
 
==== Davis Connection ====
 
As you guessedwill guess, here is where you enter settings for how Cumulus interacts with your Davis station, see hints by selections.
 
==== Davis WeatherLink Live ====
==== Log interval ====
 
This is '''interval''' time (selected from a drop-down), betweeni.e. timesthe wheninterval between one MX logslog of current values in the [[Standard log files]] and the [[Extra Sensor Files]] and the next entry in those logs.
*A ''shorter'' time interval here has advantage of a greater chance of logging daily maximum and minimum values, but leads to bigger files. Because the log only records spot values (not, as one Cumulus 1 enhancement requested, maximum and minimum since last log entry, which is the approach taken by one of Cumulus's software rivals) there remains a good chance of missing the extremes when logging.
*Conversely, choosing a ''longer'' time here increases chancethat ofprobability notof recordingmissing extremes, but reduces the storage needs on the device running MX.
*For some weather station types, thisthat intervaldon't shouldhave matcha theseparate intervallogger, atwhen whichMX theis loggernot associatedrunning withno theweather stationdata logsis readingscaptured, forso somethe typesstandard itand doesextra notsensor matter,logs andwill someonly stationcover typestimes don'twhen haveMX ais separaterunning. logger.
*If the weather station you use has a separate logger, setting the log interval here to match the interval used by the separate logger means that on restarting MX when it reads '''archive data''' during catch-up it will store spot values at the same interval whether storing archive or live data
**Davis stations in particular can struggle to do a correct catch-up when MX is restarted if the intervals do not match, and that catch-up download can be of every log in the logger and take a long time.
**CalculationsIf likethe averagestation temperaturelogger interval and windthis runlog interval are basedset onto everysame, measurementthen processedentries byin MX.the Iflog youfiles don'twill runbe at same interval when MX allis therunning time,and itwhen canthe onlyCumulus processlog whatentries isare inpopulated thefrom station loggerlog forentries. theIf timesthey whendisagree, MXthe isCumulus notlog running.will Anstore averagelines willat bethe skewedstation iflogging someinterval ofduring thereading inputsarchive toon thatrestart averageand areat basedthe oninterval rapidset samplinghere whilewhen MX is running andnormally; someyou onmight infrequentnot want your Cumulus logs whento ithave isan notinconsistent runninginterval.
**The normal reason for disagreement between the MX interval and separate logger interval is when MX may be stopped for long periods; most separate loggers are cyclic, they overwrite older entries, so the interval for the separate logger is selected long enough to avoid any chance of over-writing during the period when MX is not running; whilst the MX interval is set short enough to maximise the number of spot readings stored.
**If the station logger interval and this log interval are set to same number, then entries in the log files will be at same interval when MX is running and when the Cumulus log entries are populated from station log entries. If they disagree, the Cumulus log will store lines at the station logging interval during catch-up on restart and at the interval set here when MX is running normally; you might not want your Cumulus logs to have such a mixture.
**When MX is restarted and reads archived readings, Davis stations, in particular, can struggle to do a correct catch-up if the intervals do not match; with Davis stations MX can be forced to download every log in the logger and thus be stuck in reading archive stage for a long time.
**If the station log interval is too short, the station logger might not hold enough entries if the Cumulus user is not able to keep MX running continuously or if MX fails for some reason. This tends to be the reason why some users want their station logger interval longer; they need to be able to retain say whatever length of time they might be on holiday. So some people will set that station interval to longer than this Cumulus interval (for normal running, they wish to maximise the values that are logged).
*Calculations like average temperature (calculated by summing all processed measurements and dividing by number of samples) and wind run (calculated by summing all wind speeds and dividing by sum of all intervals between processed measurements) are biased if there is an inconsistency in interval between measurements being processed by MX. If you don't run MX all the time, it can only process what is in the station logger for the times when MX is not running. An average will be skewed (and so not an accurate average) if some of the inputs to that average are based on rapid sampling while MX is running, and some of the inputs taken from infrequent logs when MX is not running.
 
===== Davis users =====
 
From version 3.7.0 if you use a Davis station, a warning will be output if the log interval set here does not match the Davis logger interval. The developer says:
<pre>This is just a warning. Its best to keep the logger intervals the same to avoid excessively long start-ups, but it isn't mandatory.
 
Cumulus 1 was originally designed to allow you to match meteorological practice of rollover at 9 am in winter and 10 am in summer (so all days are exactly 24 hours long even when clocks change), but other options can be set.
 
Cumulus 2 worked on UTC, so the rollover functionality was different.
 
Cumulus MX operates on the time provided by the device it is running on, it offers a choice between midnight rollover, 9 a.m. rollover, and 9 a.m. rollover adjusted when daylight saving time is reported by the device. Only the last of the 3 options (or no DST) ensures all days are 24 hours long, the other options will have a day of 23 or 25 hours when clocks change (DST starts or ends).
 
==== Location ====
#Longitude
#* The above two are entered as degrees, minutes, and seconds, as this is most accurate way to specify an angular position (internally MX uses decimal degrees with 18 decimal places as 17 of those are needed for one arc second)
#* You may need to look these up, don't forget there are 3 numbers (degree, minute, second) and a hemisphere option to select correctly for each
#* The longitude and latitude must be right to get sun rise/set calculated correctly.
#altitudeAltitude (not used in standard Cumulus functionality, but must be right if you send an alternative pressure reading to an external site)
#Name
#Description
#*The name and description are combined with other fixed words on the standard web pages, so must work in that context, and you are advised to look at the generated web page at CumulusMX/web/index.htm to check your choices work with those added words.
 
People often struggle with these settings. However, these are not settings you have to get right first time, so a mistake is a learning experience.
==== Options ====
 
You will probably find it hard to find this section as it is some way down on the Station settings web page, but it is '''an important set of settings'''.
 
Some settings offer choice from just two options as summarised in the table. The othersother Options settings are described below table.
 
 
==== Annual Rainfall ====
 
ThisThe terminology here might be confusing, MX allows you to report seasonal rainfall, i.e. optionally what is reported as '''this year's rain''' starts on the first of September say, rather than 1 January. If, you don'tYou choose January,by there isselecting a difficultymonth witha the year-to-date and year to which it applies, because these are always applied January to December and will therefore cover parts"Start of two different seasons! The advice is to review these settings every month and check whether you want them to still apply or need to reviserainfall themseason".
 
However, the way MX has been written, does not fully implement this functionality, and users might not see the correct annual rainfall figure in all months of their season. MX calculates the figure it reports for '''this year's rain''' by summing:
#the rainfall it reports for today
#the amount in "year to date" entered here, if current calendar year matches the "Year to which year-to-date amount applies" entered here
#the amount in dayfile.txt (daily rainfall field) for each log file line starting with one with date matching First of month specified in "Start of rainfall season" and continuing to end of file.
 
If, you don't choose January here, ''there is a difficulty with the year-to-date and year to which it applies'', because MX assumes the "year-to-date" is applied January to December of the "Year to which year-to-date amount applies" and will therefore incorrectly alter the '''this year's rain''' during parts of two different seasons! Consequently, as you go from December to January your "year-to-date" rainfall amount reported suddenly decreases; and when the month changes to that specified in "Start of rainfall season", you find the season re-starts with not zero rain but with '''this year's rain''' added in again!
 
The advice is to review these settings every month and check whether you want them to still apply or need to revise them.
 
==== Graphs ====
=== Internet Settings ===
 
All settings entered here are stored in [[Cumulus.ini]]. No settings take effect until '''Save''' button pressed. [[File:Include graph data files.PNG|right]]
This has a lot of similarities with the [[Cumulus_Screenshots#Sites.2FOptions_Tab|Cumulus 1 settings]], except that this screen only covers what was on the main tab in Cumulus 1. Again there are hints, MX has more options than Cumulus 1 had, and some defaults are different in the two flavours. No settings take effect until '''Save''' button pressed.
 
All retain their settings when MX is restarted. No settings take effect until '''Save''' button pressed. This includes '''FTP logging''' in '''Web/FTP settings''' section, (it is not in this image as it is further down), which is used to add additional information to [[MXDiags]] about standard File Transfer Process actions; it will persist across stopping and restarting MX, so you must switch it off here (or with MX stopped within [[Cumulus.ini#Section:_FTP_site|Cumulus.ini '''FTP site''' section]].
[[File:Include graph data files.PNG|right]]
 
The MX settings on this web page have a lot of similarities with the [[Cumulus_Screenshots#Sites.2FOptions_Tab|Cumulus 1 settings]]
In Cumulus 1, you had one setting to upload the standard files and that included web pages, moon image, and the graphs. MX has separate selection settings for the uploading the standard files (web pages), the include graph files (JSON files used by charts), for generating the moon image, and for uploading the moon image. See image where the graph file option is arrowed.
*this MX web page does not cover all of the Cumulus 1 Internet Settings.
*MX has more options than Cumulus 1 had,
*some defaults are different in the two flavours.
 
Like Cumulus 1, MX has an '''External Programs''' section. Here you can enter a command and (in separate box) parameters for 3 possible timings (at real-time, at interval, and at end of day). Typically, on a windows device you would enter the name of a batch file (filename ends in .cmd). On a device running Linux, it could be a shell command file (ends in .sh) or indeed a command like "php" to run a php script whose name is specifed in parameters box. The final parameter might be preceded by ">" to direct the output to a log file.
All settings entered here are stored in [[Cumulus.ini]].
 
*In Cumulus 1, you had one setting to upload the standard files (web pages) and a second setting to upload the standard images (moon image, and the graphs)
All retain their settings when MX is restarted. No settings take effect until '''Save''' button pressed. This includes '''FTP logging''' in '''Web/FTP settings''' section, (it is not in this image as it is further down), which is used to add additional information to [[MXDiags]] about standard File Transfer Process actions; it will persist across stopping and restarting MX, so you must switch it off here (or with MX stopped within [[Cumulus.ini#Section:_FTP_site|Cumulus.ini '''FTP site''' section]].
*MX has one option for the "uploading the standard files" (web pages), a second option "include graph files" (JSON files used by charts), a third option for "generating the moon image", a fourth option for "uploading the moon image". See image where the graph file option is arrowed.
 
Each section for an external web site has a number of parameters to set, once set MX will automatically upload to that site the weather values in the correct format. Windy has been added to the external web sites that can be automatically updated. No settings take effect until '''Save''' button pressed.
 
The main new feature (not in Cumulus 1) within this settings page is a '''Custom Http''' section. Within here you can define commands (in URL format) to be executed either at some multiple of seconds interval, and/or at a selected intervals in minutes, and/or at end of day (in [[#MX_End_of_Day_Process|EOD sequence shown below]], the Custom HTTP is run before external programs are run, and that is before upload of Extra Files at EOD). In each of these you can use web tags to supply values for parameters to the command. Typically this would be used to send information to a remote web server. Here is a Custom HTTP example <pre>https://the_URL_here/your_api_here?winddir=<#avgbearing>&windspeedmph=<#wspeed>&windgustmph=<#wgust>&tempf=<#temp>&rainin=<#rhour>&baromin=<#press>&dewptf=<#dew>&humidity=<#hum>&uv=<#UV>"</pre> No settings take effect until '''Save''' button pressed. You need to turn on enhanced debug logging to see any confirmation that the http has run:
*In each of these you can use web tags to supply values for parameters to the command.
*Typically this would be used to send information to a remote web server.
*Here is a Custom HTTP example <pre>https://the_URL_here/your_api_here?winddir=<#avgbearing>&windspeedmph=<#wspeed>&windgustmph=<#wgust>&tempf=<#temp>&rainin=<#rhour>&baromin=<#press>&dewptf=<#dew>&humidity=<#hum>&uv=<#UV>"</pre>
*No settings take effect until '''Save''' button pressed.
*You need to turn on enhanced debug logging to see a confirmation that the http has run such as that shown here:
<pre>
2018-07-21 16:05:00.821 Custom HTTP Minutes update
 
=== Extra Web Files ===
This is an extension of the Cumulus 1 facility on the "Files" tab of its Internet Settings. How to use these settings is explained for both Cumulus flavours on [[Customised_templates#What_to_select_on_the_.27Files.27_tab_of_the_Internet_Settings_screen_within_the_.27Configuration.27_menu|this wiki page]], MX has an extra "end of day" (EOD) option, but otherwise you fill it out exactly the same way. Settings in one table cell are stored when you click in another table cell. Although, there is no Save button as clicking in another cell stores previous edit, the "Enter" button on many keyboards can optionally be used to be sure you have saved all edits made before you leave the screen.
 
This is an extension of the Cumulus 1 facility on the "Files" tab of its Internet Settings.
Although to tick both real-time and EOD seems nonsensical, MX will let you for any selected file(s) do the processes and uploads at both intervals. I don't see why you should do that for normal running, but you might tick both to test a template without waiting for EOD, and after it has been processed once, remove the unwanted real-time tick, so from then onwards it just happens at EOD.
 
How to use these settings is explained for both Cumulus flavours on [[Customised_templates#What_to_select_on_the_.27Files.27_tab_of_the_Internet_Settings_screen_within_the_.27Configuration.27_menu|this wiki page]], MX has an extra "end of day" (EOD) option, but otherwise you fill it out exactly the same way. Settings in one table cell are stored when you click in another table cell.
'''If you have moved from Cumulus 1''', and are therefore using an existing Cumulus.ini, these screens may be partly pre-populated, despite that you might need to:
 
# change some paths in local column, as you may be referencing some files moved when you installed MX
Although, there is no Save button as clicking in another cell stores previous edit, the "Enter" button on many keyboards can optionally be used to be sure you have saved all edits made before you leave the screen.
#*if you have moved to a Raspberry Pi, or other Unix-derived operating system, remember that path names in Windows use "\" as directory separator, but all other systems use "/". There is more advice available at [[Setting_up_Raspberry_Pi#Configuration_files]].
 
# untick one column, and tick another, now that EOD is an option for the timing as well as real-time and normal logging/ftp interval.
Although to tick both real-time and EOD seems nonsensical, MX will let you tick both for any selected file(s), as it wil then do any processes, and uploads, at both intervals. I don't see why you should do that for normal running, but you might tick both to test a template without waiting for EOD, and after it has been processed once, remove the unwanted real-time tick, so from then onwards it just happens at EOD.
 
'''If you have moved from Cumulus 1''', and are therefore using an existing Cumulus.ini, these screens may be partly pre-populated, but because mX adds extra options you might need to:
# change some paths in local column, (if your Cumulus 1 and your MX locations are different)
#*if you have moved to a Raspberry Pi, or other Unix-derived operating system, remember that path names in Windows use "\" as directory separator, but all other systems use "/".
#*There is more advice available at [[Setting_up_Raspberry_Pi#Configuration_files]].
# untick one column, and tick another, now that EOD is an option for the timing as well as real-time and (normal logging/ftp) interval.
# edit some templates (local files) where the process column is ticked because of [[Webtags|Web tags differences]] (some output modifiers are interpreted differently), you will need to revisit every web tag in every template to check whether the output format will need to be added, or amended, to give the output you want.
# you should not need to change remote file names, providing that you have not changed any directories on your web site as (like in Cumulus 1), for extra files, the remote path/file name required ignores any directories specified on Internet Settings screen for FTP settings.
#*if you host your own web server, then you might need to change remote paths, if you have moved your server to a new device
#*if you use a web server provided by a hosting company, and you change to a different company or they update their offering, then again you might need to update remote column
#* the exception to this is if either you host your own web site and/or you are moving them web site to a new location; in these cases your remote file paths may need updating.
 
=== Calibration settings ===
 
This is identical to [[Cumulus_Screenshots#Calibration|Cumulus 1 screen]] functionality, already explained in [[FAQ#I_get_very_large_amounts_of_rainfall_shown.2C_or_other_high_readings|Cumulus 1 FAQ here]] and [[Dayfile.txt#Dealing_with_rogue_measurements|"Dealing with rogue measurements"]] in this wiki.
 
 
===== Another daily summary table =====
 
*2. ''Custom upload - at rollover''
** Use this option with '''caution''' - I found that when I ran MX on a Windows PC, this feature worked (although I abandoned it as it did not do all I wanted), but when I tried this feature with MX running on a Raspberry Pi it simply did not work (the first few web tags used reported correctly the values from day that had just ended, but subsequent web tags, from dew point in example below, were useless as they reported the values from first minute of day just starting - the SQl runs in a separate thread in MX to that handling web tags and it appeared the web tags rolled over before the SQL finished even being defined by MX!
** In the previous option, you have no ability to vary the schema, it will update a column for Total Evaporation even if your weather station cannot calculate that. It will update columns for total hours of sunshine, highest solar radiation level, and the maximum UV in the day even if you cannot measure these. It will not record whether snow was falling or lying, or the depth of snow if you wanted to be recording those.
** In the previous option, you have no ability to vary the schema (which columns are updated), it will update a column for Total Evaporation even if your weather station cannot calculate that. It will update columns for total hours of sunshine, highest solar radiation level, and the maximum UV in the day even if you cannot measure these. It will not update columns for other parameters that Cumulus processes like Lightening, Soil Moisture, pollutant values, Chill Hours, for whether snow was falling or lying, or the depth of snow if you wanted to be recording those in your daily summary.
** MX provides this alternative option, again doing an upload as part of roll over to next day ([[#MX_End_of_Day_Process|sequence shown below]], the Custom EOD SQL is run after the day reset to new date, but before the dayfile.txt update with existing values and so before today.ini to yesterday.ini processing).
** MX provides this alternative option, again doing an upload as part of roll over to next day ([[#MX_End_of_Day_Process|sequence shown below]], the Custom EOD SQL is run after the day reset to new date.
**In this section you can specify the schema, and say which columns are to be updated with three selections:
**# Save - a button after all option sections, until you click it any changes you make in this section have no effect
**# A tick box to enable or disable this upload (so you can leave the SQL recorded, but stop running it when you like.
**# The SQL you want to run, what you type in this small text box should include INSERT IGNORE (or REPLACE) to insert a row, or include UPDATE to change columns in a row that already exists, like any SQL it must include the name of the table, the columns to be updated, and the values you want to insert into the columns are either expressed as web tags, as SQL functions on web tags, or as a sub-query reading the values from somewhere else.
**#* Here is an example of a suitable query that MX can process for you
**#* Here is an example of a suitable query that MX can process for you [note I have had to include some yesterday tags e.g. for primary key ('''<#metdateyesterday format=yyyy-MM-dd>''', I have used the SUBSTRING function at one point, and also be aware that the column names listed here are different from the previous example but if you are doing a custom update it will be because you have different column names! I don't have a sub-query in this example, but any SQL that is syntactically valid could appear here, and you could have more than one query in sequence.):
**#**[note includes yesterday tags e.g. for primary key '''<#metdateyesterday format=yyyy-MM-dd>''', but as caution above says it might, or might not, process correct web tag content so other web tags migt also need to be yesterday versions),
**#*I have used the SUBSTRING function at one point,
**#*as it is a custom update the column names listed here are different from the standard example
**#*I don't have a sub-query in this example, but any SQL that is syntactically valid could appear here, and you could have more than one query in sequence.
<pre>INSERT IGNORE INTO `test_daily_summary` (`MaxRainRate`, `TMaxRainRate`, `HighHourRain`, `THighHourRain`, `TotRainFall`, `SnowFalling`, `SnowLying`, `SnowDepth`, `CumChillHours`, `LogDate`, `RollOver`, `MinTemp`, `TMinTemp`, `HeatDegDays`, `AvgTemp`, `MaxTemp`, `TMaxTemp`, `CoolDegDays`, `LowDewPoint`, `TLowDewPoint`, `LowHum`, `TLowHum`, `HighHum`, `THighHum`, `HighDewPoint`, `THighDewPoint`, `GreatWindChill`, `TGreatWindChill`, `LowAppTemp`, `TLowAppTemp`, `HighAppTemp`, `THighAppTemp`, `HighHeatInd`, `THighHeatInd`, `MinPress`, `TMinPress`, `MaxPress`, `TMaxPress`, `HighAvgWSpeed`, `THighAvgWSpeed`, `StrongestWindGust`, `TStrongestWindGust`, `BearStrongestWindGust`, `BearStrongestWindGustSym`,`BearDomWind`, `BearDomWindSym`, `TotWindRun`) VALUES ('<#rrateTM>', '<#TrrateTM>', '<#hourlyrainTH>', '<#ThourlyrainTH>', '<#rfall> ', '<#snowfalling>', '<#snowlying>', '<#snowdepth>', '<#chillhours>', '<#metdateyesterday format=yyyy-MM-dd>', '(1 * SUBSTRING(<#rollovertime>,0,2))', '<#tempYL>', '<#TtempYL> ', '<#heatdegdays> ', '<#avgtemp>', '<#tempTH>', '<#TtempTH> ', '<#cooldegdays> ', '<#dewpointTL>', '<#TdewpointTL>', '<#humTL>', '<#ThumTL>', '<#humTH>', '<#ThumTH>', '<#dewpointTH>', '<#TdewpointTH>', '<#wchillTL>', '<#TwchillTL>', '<#apptempTL>', '<#TapptempTL>', '<#apptempTH>', '<#TapptempTH>', '<#heatindexTH>', '<#TheatindexTH>', '<#pressTL>', '<#TpressTL>', '<#pressTH>', '<#TpressTH>', '<#windTM>', '<#TwindTM>', '<#wgustTM>', '<#TwgustTM>', '<#bearingTM>', '<#directionTM>', '<#domwindbearing>', '<#domwinddir>', '<#windrun>', '<#feelslikeTH>','<#TfeelslikeTH>','<#feelslikeTL>','<#TfeelslikeTL>','<#humidexTH>','<#ThumidexTH>');</pre>
** Again before you enable this option, there is a facility lower down this setting page (under the heading '''Create database table''') where you can type some SQL to be run immediately, that can create the table you want this option to update, (although it could even populate any table with historic data, it is only intended for a small query). I am using a table that already exists as I have used it for testing changes to my PHP scripts, so I did not need to create a table before I enabled the query shown above.
 
===== Standard Monthly table =====
 
*3.''Standard log file upload''
**Cumulus starts a new log file for each new month, that is why this is called the monthly log.
 
===== Table created from Standard and/or Extra Sensor Log files =====
 
*4. ''Custom upload - minutes interval''
** One way you could use this option, is to replace the monthly log file upload if you wanted to change the schema, by leaving out some columns if your weather station is not able to measure all the derivatives included in the standard schema.
** You could use this option to add columns that represent fields in your Extra Sensor log file, by specifying the corresponding web tags
** This feature allows you to specify your own SQL for an upload to be repeated every NN minutes. Unlike the Monthly log file upload option you choose what schema (columns) are in the table that you are uploading a new row to and indeed exactly what SQL is used.
**Apart from the need to press the Save button that follows all the options, there are 3 items just for this option:
 
===== Table updated at real time interval =====
 
*5. ''Realtime.txt upload''
** Cumulus MX can be set to recreate a file called [[Realtime.txt]] on a very frequent basis. The real time interval defines the time from the end of doing one real time update until the start of the next real time update. The file is recreated, in that unlike other log files, MX does not add new rows in each update, the file only ever contains a single line of values.
 
===== Another table unpdated at an interval measured in seconds =====
 
*6. ''Custom upload - seconds interval''
** This feature allows you to specify your own SQL for an upload to be repeated every NN seconds. This caters for when you want something like the values in "realtime.txt" but want to specify your own schema (set of column names) or your own interval between updates (independent of what has been selected for real-time interval). Like the other custom options, this might be because you have extra sensors or do not have sensors for all items in standard log file.
 
=== Alarms ===
This is identical to Cumulus 1 functionality, apart from using a new default location for the files "\CumulusMX\interface\sounds", the alarms available are already explained [[Cumulus.ini#Section:_Alarms|elsewhere]] in this wiki.
 
This is identical to Cumulus 1 functionality, apart from using a new default location for the files "\CumulusMX\interface\sounds", and the list of alarms available is extended in MX compared to Cumulus 1.
The alarms are shown at the bottom of the Dashboard page of the user interface. They also feed a set of [[Webtags#Alarms|Webtags]].
 
The alarms available are already explained [[Cumulus.ini#Section:_Alarms|elsewhere]] in this wiki, so are not repeated here.
 
Some alarms are shown at the bottom of the Dashboard page of this administrative interface. They also feed a set of [[Webtags#Alarms|Webtags|web tags]] so you can use them in web pages.
 
=== FTP Now ===
 
This is similar to the option in the file menu of Cumulus 1 to do an update now. Depending on which build of MX you are using, the functionality varies. On latest build it does whatever updates are set up to happen at normal updating interval whether these are by FTP to your web site, or by copying files between local and remote filenames with path (although both could be on same device).
 
== Editing the Admin Interface ==
 
The admin interface provided with MX is generated from some application programming interface (api) produced by MX engine, some JSON files specifying options, some JavaScript files populating content, some cascade styling sheet files determining look, and some HTML files specifying structure. Theoretically, all of this could be customised to suit you as the developer's choices might not match your desires.
 
=== Caution against editing Admin Interface ===
The general advice is do not change any files that are part of the MX package, they are a package and therefore there are interdependencies. Also updating to a newer release is more complicated if you have edited any files. The files as provided in the MX package are a compromise, for example they include reporting on solar measurements but not all weather stations include such measurements. Given that the admin interface is not shared with anyone else, it could be argued its look and content is not that important. In particular this interface is the only way to change settings, so do not change anything that stops those setting screens from working!
 
The general advice is do not change any files that are part of the MX package, they are a package and therefore there are interdependencies. Also updating to a newer release is more complicated if you have edited any files, because you need to implement any changes in that release and they will overwrite any edits you have made.
Finally, if you don't like the look of the admin interface, then why not look at your web pages, apart from settings, they should show you the same information, and you can edit your web pages to show information in whatever way suits you.
 
The files as provided in the MX package are a compromise, for example they include reporting on solar measurements but not all weather stations include such measurements.
 
Given that the admin interface is not shared with anyone else, it could be argued its look and content is not that important. In particular this interface is the only way to change settings, so do not change anything that stops those setting screens from working!
 
Finally, if you don't like the look of the admin interface, then why are you looking at the admin interface? If it to change settings, does it matter how it looks? If you are looking at the admin interface to see your weather readings and derivations, then why not look at your web pages, as you can edit your web pages to show information in whatever way suits you.
 
=== Caution when updating if you have edited Admin Interface ===
 
Remember, if you decide to download a new release to not overwrite any file(s) that you have edited, or your edit will be lost. It is less likely that a new release will change the interface files than other files, but some releases do change these files. Remember, each release zip contains all MX files, even those not changed since previous release. The release notice will usually give some idea of whether interface files have changed, but it may not list which interface files have been added, modified, or removed.
Remember, if you decide to download a new release if you overwrite any file(s) that you have edited, your edit will be lost. It is less likely that a new release will change the interface files than other files, but some releases do change these files. Remember, each release zip contains all MX files, even those not changed since previous release. The release notice will usually give some idea of whether interface files have changed, but it may not list which interface files have been added, modified, or removed.
 
=== General points for editing ===
 
If you do decide to change any file, I suggest you maintain a back-up copy of the original elsewhere (so it can be gone back to) and you save the edited file under a new name (so you can't lose my edited file by installing a new release).
 
If you are editing files, use Brackets, Notetab lite, notepad++ (for windows), or BB-edit on a Mac BB-edit, i.e. ''use an editor designed for code,''. doDo not use a word processor, a Microsoft or Google editor or Dreamweaver or any other web editor. The encoding that should be used is UTF, if your editor does not mention encoding, it is the wrong sort of editor!
 
=== Changing the look ===
 
You need some understanding of Cascading Style Sheets (CSS) to do this, but all you need to do is to edit the relevant style sheet either in '''\CumulusMX\interface\css''' or in the relevant folder within the lib folder.
You need some understanding of Cascading Style Sheets (CSS) to do this, but all you need to do is to edit the relevant style sheet either in '''\CumulusMX\interface\css''' or in the relevant folder within the lib folder. Beware, making a change to make one web page in the admin interface look right, might ruin web page in the interface, so making changes is not easy!
You may feel that the default look of grey, black, and white, is either boring or does not offer sufficient contrast for you, perhaps you feel certain font sizes are too small, or you want to change the page background. Well, you can change the look, it is all defined in .css files. However, because MX makes use of standard libraries (bootstrap, datatables, alcapa etc.) there are a multitude of .css files used and it might not be easy to work out which one to edit. Each HTML page has links to a number of css files. You will probably make use of developer functions in your browser to inspect any element whose look you wish to change to see where its different properties are defined. It is better to make any such edits at a high level, rather than on any CSS just for that particular element. As always when editing, keep a copy of original so you can go back to it; keep a copy of your edited file, so installing a new release does not lose you edited file.
 
You can change the look, it is all defined in .css files. However, because MX makes use of standard libraries (bootstrap, datatables, alcapa etc.) there are a multitude of .css files used and it might not be easy to work out which one to edit. Each HTML page has links to a number of css files.
 
You will probably make use of developer functions in your browser to inspect any element whose look you wish to change to see where its different properties are defined. It is better to make any such edits at a high level, rather than on any CSS just for that particular element. But don't forget to check every web page in the interface still looks okay as if you do make a change to improve one page it may worsen another page.
 
As always when editing, keep a copy of original so you can go back to it; keep a copy of your edited file, so installing a new release does not lose you edited file.
 
=== Removing Solar Figures ===
 
If your weather station does not have solar instrumentation you might wish to remove some of the display elements that relate to that. You need some understanding of Hyper-Text Markup Language to do this correctly, but here are simple examples.
If your weather station does not have solar instrumentation you might wish to remove some of the display elements that relate to that. Of course they will come back when the next release overwrites your change!
 
You need some understanding of Hyper-Text Markup Language to do this correctly, but here are simple examples.
# Navigate to '''\CumulusMX\interface''' folder.
# Open the file '''now.html''' in an editor designed for code (e.g.some Notepad++examples forwere Windows,listed Notetab Liteearlier)
# Near the bottom of the file edit it by inserting HTML comment delimiters (opening after &lt;/thead>, closing before &lt;/table>) so it looks like this:
<pre><table id="SolarTable" style="width:100%">
IMPORTANT NOTES:
#The above approach works on "now.html", but it does not work on other pages where table rows are dynamically created by an external script, so the existing rows in the table body are dummies whose content is ignored.
*An alternative technique is to delete the whole table and any "&lt;div> ... &lt;/div>" that surrounds only that table, thatdeleting entire code willshould work on all the HTML pages.
 
=== Adding derivatives not shown on the existing admin interface page ===
 
It is a JavaScript file '''\CumulusMX\interface\js\dashboard.js''' that reads the real-time file and inserts particular content into position indicated by values of the HTML attribute "id" on the admin interface screens. The standard '''\CumulusMX\interface\now.html''' does not include temperature trend for example, but because there is a '''temptrend: inp.TempTrend.toString()''' defined in the JavaScript file, you can easily add it to the "now" page by a simple insert of the middle row here:
An application processing interface (api) is used to obtain the values (or in some cases entire tables) shown on many of the web pages in the admin interface. These api are hard coded within the MX code and so you can not edit them. However, in a few cases, the api being used does provide more values than are coded to be shown on a web page. The standard '''\CumulusMX\interface\now.html''' does not include temperature trend for example, but because there is a '''temptrend: inp.TempTrend.toString()''' defined, you can easily add it to the "now" page by a simple insert of the middle row shown here in its context:
<pre><tr>
<td>Outdoor Temperature</td>
<td><span class="TempUnit">--</span></td>
</tr></pre>
You can't add any derivatives into any table unless the value (for the derivative you want to add) is already defined in the related api and JavaScript files.
 
There is a section of the support forum devoted to [https://cumulus.hosiene.co.uk/viewforum.php?f=28 Cumulus MX interface customisation], so you can see what other people are doing. There is also [https://cumulus.hosiene.co.uk/viewforum.php?f=36 another sub-forum] for making suggestions on what you would like added to MX.
Sfws
5,838

edits

Retrieved from "https://www.cumuluswiki.org/a/Special:MobileDiff/7251"