Webtags (preserving history): Difference between revisions

From Cumulus Wiki
Jump to navigationJump to search

Webtags (preserving history) (view source)

Revision as of 08:13, 12 April 2021

50,187 bytes removed ,  08:13, 12 April 2021
m
→‎Recent History: reference to examples added
m (→‎Recent History: reference to examples added)
(16 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[Category:Terminology]]
[[Category:Terminology]]
=What is a web tag? =
Put simply, a web tag is included in a Cumulus template file to indicate where Cumulus should insert values when it produces an output file. The concept of [[Customised_templates#What_is_meant_by_.27Cumulus_processes_templates.27|processing templates]] is explained in another article.
The output file can be:
* a [[Customised_templates#HTML_5_-_a_very_quick_guide_to_structure|web page]],
* a  [[Php_webtags#Option_3:_JavaScript_Object_Notation|JavaScript_Object_Notation (.json) file]]
* a [[Feels_Like#HTML_code_to_translate_web_tags_to_JavaScript_variables_.28as_modified_for_additional_parameters.29|JavaScript file]],
* a [[PHP]] script file, or
*a [[Xml_webtags|eXtensible Mark-up Language (XML)]] file.


<div style="background: LemonChiffon;padding:5px; margin:2px;">
<div style="background: LemonChiffon;padding:5px; margin:2px;">
Line 20: Line 7:
</div>
</div>


=Introduction=


{{TOCright}}
==What is a web tag? ==


== Why does MX talk about tokens? ==
Put simply, a web tag is included in a [[Cumulus template file]] to indicate where Cumulus should insert values when it produces an output file. The concept of [[Customised_templates#What_is_meant_by_.27Cumulus_processes_templates.27|processing templates]] is explained in another article.


MX uses a '''token parser''' to read the web tags and replace them with the correct value, so if diagnostic output refers to tokens, it is saying the attempt to actually work out what content to return to replace the web tag with its tag name and parameters has encountered a problem.
==Template files can create many types of file==


=GENERAL TIP=
The output file can be:
* a [[Customised_templates#HTML_5_-_a_very_quick_guide_to_structure|web page]],
* a  [[Php_webtags#Option_3:_JavaScript_Object_Notation|JavaScript Object Notation (.json) file]]
* a [[Feels_Like#HTML_code_to_translate_web_tags_to_JavaScript_variables_.28as_modified_for_additional_parameters.29|JavaScript file]],
* a [[PHP]] script file, or
*a [[Xml_webtags|eXtensible Mark-up Language (XML)]] file.


The web tags available in the version/build you are using, can be listed (in Cumulus 1 or Cumulus MX) by adding the following line to [[Cumulus.ini#Section:_Station|Cumulus.ini]] in the [station] section...
==General Format for Web Tags==


  ListWebTags=1
In the position in any template file where Cumulus is to insert the relevant data, place a web tag in the '''general format''' specified here: <pre><#tag_name [optional input selection parameters] [optional output modification parameters]></pre>


Then start Cumulus and it will create a file called WebTags.txt in the same folder as where the executable is found. That file will list all the tags your build of Cumulus can currently generate. This list only contains the tag_names, it does not indicate what parameters they can take, nor does it include the brackets the tag name is surrounded by when you quote it in a template file for Cumulus to process.  
To find out what is allowed for '''tag_name''', see the various tables later on this page.


An example of the output for an early MX version is at the end of this page (the actual output does not include commas, and has just one item per line, it has been compressed for inclusion in this article).
To find out what is allowed for the '''input selection parameters''' and '''output modification parameters''', refer to [[Webtags/Parameters|web tag parameters]] page.


To stop Cumulus continuing to produce new versions of that file change the line to say ...
==What this page covers ==
 
ListWebTags=0
 
{{Version badge 1}}If you are using Cumulus 1, each build of that contains a build specific version of Cumulus Help, and within that help is a list of web tags with basic information on what each tag_name returns.
 
=What this article covers =


{{TOCright}}
#At the last count, a 3.5.x version of MX produces ''nine and a half million'' '''web tags'''!   
#At the last count, a 3.5.x version of MX produces ''nine and a half million'' '''web tags'''!   
# Those millions of web tags can actually produce billions of different outputs!
# Those millions of web tags can actually produce billions of different outputs!
Line 55: Line 43:
Consequently, this article describes:
Consequently, this article describes:
*Over 7 hundred web tags -'''THIS ARTICLE MAY NOT CONTAIN ALL WEB TAGS AVAILABLE IN LATEST VERSION - It depends on someone updating this article if the developer does not have time to do so'''
*Over 7 hundred web tags -'''THIS ARTICLE MAY NOT CONTAIN ALL WEB TAGS AVAILABLE IN LATEST VERSION - It depends on someone updating this article if the developer does not have time to do so'''
==What is covered on another page==
The parameters you can use with web tags are explained on the [[Web Tag Parameters|parameters page]], there you can discover:
*A score of input parameters that modify some of those tags (meaning some web tags can represent 12 different months for example)
*A score of input parameters that modify some of those tags (meaning some web tags can represent 12 different months for example)
*The components that make up output parameters (a guide to how you modify the output format)
*The components that make up output parameters (a guide to how you modify the output format)
** some control number of decimal places
**how to control number of decimal places
** one controls whether decimal comma (if used) is replaced by decimal point (useful for some script languages)
**how to control whether decimal comma (if used) is replaced by decimal point (useful for some script languages)
**the majority modify the output from almost all web tags that report a time and/or date (there are so many ways to represent times and dates this multiples up the available output considerably)
**the majority modify the output from almost all web tags that report a time and/or date (there are so many ways to represent times and dates this multiples up the available output considerably)


Line 64: Line 56:
The tables below are not able to indicate which of the billions of combinations possible are valid or invalid for particular tag names nor for particular release versions..
The tables below are not able to indicate which of the billions of combinations possible are valid or invalid for particular tag names nor for particular release versions..


==Applicability by version and build==
==Applicability by flavour, and by release version and build==


The tip at the start of this article tells you how to check which tags are available in whatever build of Cumulus you are actually using. Given how often a new release alters either what web tags are available or what parameters can be used with particular web tags, it is possible the tables below do not list all web tags at any version, and the tables can't say which modifiers are available at your version.
Full support is available via the support forum at https://cumulus.hosiene.co.uk/viewforum.php?f=40 for the latest MX release. Given that some users may still be running an older MX release, where possible any web tag listed below for MX indicates at which release it first became available.


Because Cumulus 2 is no longer available, it has been ignored in the tables below.  It never really worked for web page generation, so if you happen to have installed Cumulus 2 from when it was available, you probably don't care which web tags it supports.
There is limited support available for Cumulus 1.9.4, but on this page every attempt is made to indicate which version of the legacy software introduced any web tag listed below as being available in the legacy software.  


[[File:Badge v1.png]]This badge is used to highlight text that applies to Cumulus 1.
Various approaches are trialled in the list for indicating which flavours a web tag exists for.  The [[Webtags#Davis|Davis]] section has a column that indicates the applicability. Other sections with more web tags use pink section headings to identify their applicability to the flavours. Finally, there are some individual entries where '''C1''' and '''MX''' symbols are used to indicate applicability.
*Use of this badge does NOT mean that all builds of Cumulus 1 are able to use the web tag.
*There are gaps in the Cumulus 1 documentation, and so it is not usual for the table entry to indicate when a particular web tags started to be available
*If you are using the final version of Cumulus 1, then the text highlighted by that badge does apply to you.
*In general, Cumulus 1 will silently ignore any web tag it does not recognise. This means that you might see the raw
web tag remaining after processing, or you might see nothing where the web tag was prior to processing. It also means that if you try to do a numeric calculation on a web tag that Cumulus 1 does not recognise, the calculation will fail, but you might not see an error message.


[[File:Badge vMx.png]]<big>This badge is used to highlight text that applies to Cumulus 3 (MX) for any release with version numbers 3.0.0 to 3.9.7 ONLY.</big>
There is some more information on [[Webtag Applicability|Web tag Applicability page]].
*In many cases, it highlights web tags that are not available in Cumulus 1
*Use of this badge does not mean that all builds of MX are able to use this web tag
** Web tags can only be used with template files (Steve Loft names these files in format "xxxxxxT.htm") and none are provided in MX release 3.10.1 or later.
**Some attempt has been made to indicate '''either''' which MX build introduced individual tags, '''or''' from which build the web tag started giving the correct response (where earlier builds reported incorrect values for that web tag in some cases).
*You can, even with latest MX release, create a template file using web tags, as mentioned elsewhere on this page, and fully described on the [[Customised templates]] page.
*MX will raise an error:
**for any web tag it does not recognise at the version you are running
**for any input parameter that the token parser is unable to recognise
*MX treats output parameters differently:
**any output parameter that it does not recognise at all, is ignored
**any output parameter in a web tag that '''does not''' accept output parameters is also ignored
**any output parameter in a web tag that does accept output parameters, where the supplied parameter is inconsistent with the content of the web tag, is reported as an error by the token parser
**an output parameter that specifies only part of the standard output may be reported as an error because of single character rules (for example a tag that reports a time cannot understand '''format=H''', amongst the acceptable formats are ''format=%H'' for just hour and '''format=H:mm''' for hour and minutes but not seconds.
**any output parameter that contains incorrectly formatted characters in that output parameter will be treated as an error by the token parser (a common mistake is forgetting spaces are expected to be included with other literal characters by the MX token parser)
**if you use valid parameters but the wrong parameters, you are likely to be confused by the output (the most common cases result in seeing minutes where a month is wanted, or there is a misunderstanding of the concept where the same character has different meanings when on its own and when with other characters).


= Template Files =
== Why does MX talk about tokens? ==


This is the name given by Steve Loft to any files that contain web tags and need to be processed before they actually include values.  
MX uses a '''token parser''' to read the web tags and replace them with the correct value, so if diagnostic output refers to tokens, it is saying the attempt to actually work out what content to return to replace the web tag with its tag name and parameters has encountered a problem.


When Cumulus processes these files it generates output files where the tags/tokens have been replaced by values. Consequently, a single template will actually generate a different file each time Cumulus processes that template because the part of the content that was web tags is now populated with text (values, times, dates, etc.) and as these values change that make the file different to the previous generated file.
=GENERAL TIP=


For standard Cumulus, all the output files are web pages which it then uploads to your web site. There is more about processing of files on the [[Customised templates]] page, but think of a template as containing text that Cumulus copies from the template file to the web page it is constructing. The processing process is basically a parse, each time it finds what MX calls a token (a web tag complete with any parameters it needs) it looks up the value that it will use to replace that web tag before moving on through the text.  
The web tags available in the version/build you are using, can be listed (in Cumulus 1 or Cumulus MX) by adding the following line to [[Cumulus.ini#Section:_Station|Cumulus.ini]] in the [station] section...


The example web templates provided by Cumulus insert a "T" at the end of the intended web page name before the extension (.htm or .html), so that the template files and generated web pages cannot be confused. The generated file will often have "tmp" added to the end
ListWebTags=1


When writing your own templates, some people will stick to this "T" notation, others will change the extension to "tmpl" or "cum" to indicate they are Cumulus templates. Cumulus does not care what extension is used for any local file specified in the MX '''Extra Web Files''' settings or Cumulus 1 '''Files''' tab settings.
Then start Cumulus and it will create a file called WebTags.txt in the same folder as where the executable is found. That file will list all the tags your build of Cumulus can currently generate. This list only contains the tag_names, it does not indicate what parameters they can take, nor does it include the brackets the tag name is surrounded by when you quote it in a template file for Cumulus to process.  


For Cumulus 1 and MX, there are one template held within the program code, this is what produces the default [[Realtime.txt]]. You can define an alternative template with web tags and Cumulus can process that instead of its default template.
An example of the output for an early MX version is at the end of this page (the actual output does not include commas, and has just one item per line, it has been compressed for inclusion in this article).


For MX only, there are other templates held within the program code (so you cannot edit them), these output in json format. Some are application program interface, and feed information to the admin interface, you can only view these by using the development interface in your browser that lets you see what has been loaded. The rest become the json files that are created in the '''web''' folder from where (like the web pages produced after processing the standard web templates), they can be uploaded to your web site.
To stop Cumulus continuing to produce new versions of that file change the line to say ...


= Web tags available in Cumulus =
ListWebTags=0


{{Version badge 1}}If you are using Cumulus 1, each build of that contains a build specific version of Cumulus Help, and within that help is a list of web tags with basic information on what each tag_name returns.


<div style="background: LemonChiffon;padding:5px; margin:2px;">
[[File:Badge vMx.png]] MX bug: The inclusion of a web tag in the list produced by this instruction, does not mean that web tag is actually populated with valid information. See https://cumulus.hosiene.co.uk/viewtopic.php?p=153096#p153096 for an example.
[[File:Crystal Clear info.png|40px]] This document is 'Work In Progress' so content may not be complete or accurate!
</div>


Those special markers in the file are called web tags, during processing Cumulus will replace them with the actual values.  Typically you would use this to build your own website by having an HTML template file with your layout, static text and graphics.  In the position on the page you wish Cumulus to insert the relevant data place a web tag in the form (briefly mentioned earlier in this page):


<pre><#tag_name [optional input parameters][optional output parameters]></pre>
=The web tag application programming interface=


''Note: When you put a tag into your template, be careful that whatever program you are using to develop your web pages doesn't change the angle brackets to slightly different symbols -- this is a common cause of failure!''  There are a number of editing tools that are '''designed for editing programming code''' and you should use one of those (e.g. Notepad++, Brackets, NoteTab Light, HTML kit, amongst many others), ''rather than a tool designed for web page design editing'' (e.g. Dreamweaver, word press, amongst others).
[[File:Badge vMx.png]] Available from version 3.7.0 (build 3089) released 28 July 2020. It was proposed in January 2015, see Steve Loft [https://cumulus.hosiene.co.uk/viewtopic.php?p=101496#p101496 plan to add a call where you supply a list of items (probably web tag names), and you get back the equivalent data].


== Beta Builds of Cumulus ==
== Where to use ==


{{Version badge 1}}The [[BETA webtags|additional webtags]] page was created to hold web tags that were not yet available in any Cumulus 1 formal release, but were available in any Beta version that was under development.  
This is meant for services either on the same computer as Cumulus or on your local network. It is not secure, and should not be available, nor requested, via any external network or the internet.


[[File:Badge vMx.png]]When development of Cumulus 1 ceased, Cumulus MX was available as a beta. At that time, this article continued to describe web tags available in the final release of Cumulus 1 (builds 1099, 1100, 1101, 1099.1, and 1099.2). Because the output parameters were different for MX, all the MX web tag information was in [[BETA webtags|beta web tags]] article. That was fine in early beta versions of MX because they supported only a small subset of the web tags available for Cumulus 1.
The [[MX Administrative Interface]] uses some application programming interface (api) calls to obtain the data each web page in that interface needs, and another api to return the results of any edit made. If you wanted your '''CumulusMX/interface/todayyest.html''' web page to include something else (e.g. snow falling/lying/depth) you would edit that HTML page to have the extra sub-table you want (you cannot extend the existing rainfall table as that is dynamically created by existing api) and you would edit the associated JavaScript file '''CumulusMX/interface/js/todayyest.js''' to add a new api call seeking snowdepth, snowfalling, snowlying tags for today (unfortunately there are no tags for yesterday's snow) and to place the returned values into your new sub-table (probably using jQuery to make it easy). In a similar way, you could add anything where today and yesterday tags are available such as UV Index.


In earlier versions of Cumulus if you wanted to make use of values processed by Cumulus, you wrote a script file referencing the web tags you wanted to use, and let Cumulus process that file at an interval set in the settings, then you had to write something to process the results at the relevant interval. Now if you are running other software on your device that runs MX (or a computer or other device linked directly on your personal network), you can request web tags values on demand via an application programming interface (api hereafter) and don't need to worry about any timing issues.


However, as MX development continued more and more web tags were available and maintaining two articles, one for each flavour of Cumulus was impossible. Therefore, MX users had to look at two pages, some of their web tags were in this article some were in that article. Confusingly, some web tags were in both articles, because the parameters that could be used with those tags were increased in MX, so the additional parameters were only shown in the beta article, an example was when the moon web tags had parameters added to control the output from build 3047, these were added to the Beta article.  
Obviously each api request creates a processing overhead on Cumulus so use this feature wisely (minimise the information you request and minimise the frequency of requesting it). You can use it for extra current information, but in that usage you might need to repeat the call. Consequently, maybe it is more likely that the api will be used to request information that does not keep changing, such as what units are being used for temperature, rainfall, and wind speed; or perhaps daily, monthly, or yearly, summary figures.  


When Mark Crossley brought MX out of Beta, all the web tags that were on that page were moved into this article, and it was made clear which flavours each web tag was available in (excluding Cumulus 2).  
Each admin interface web page uses api techniques for all the information it needs. Some api calls are repeated with AJAX requesting updates for the weather information on a frequent basis, but each page has another api request that is issued just once for the version and build being used.  To my mind, the design of '''CumulusMX/interface/todayyest.html''' is crazy.  The HTML appears to have a table structure, but that table structure is overwritten by each repeating api. So every time AJAX repeats that api call it returns in json format the whole table definition as well as table cell contents, despite that much of that json (all that HTML defining table header, table rows, table cells, etc.; and the units for each value) does not change and it is only some values and times buried within the json in the api that actually might change (and of those half of them, the yesterday values and times only change once a day).  In some code I wrote (but later abandoned) I made use of the api calls that support the '''CumulusMX/interface/todayyest.html''' web page to get the units I wanted on another interface page, but I only called it once as it returned a lot of other information (as just mentioned) that I did not need. I later found a better way, as in example below, which gives me just what I need and no more.


The developer of MX new releases normally shares a new version of MX first as beta by sending the distribution in an email to a number of Cumulus users. They respond by email, with the intension any issues can be ironed out before the distribution is made available as a public release.  Given the number of weather station types supported and the complexity of options for using Cumulus, this does not always ensure all ways in which MX can be used are tested, especially as the Cumulus Users given the beta test zip might not use all the features that have been modified in a particular development.
== "GET" approach ==


Although such releases often add additional web tags, any additional web tags are currently being entered into this article and no new MX web tags had been added to beta article since that move of the earlier ones into this article.
You may have used GET as an attribute when defining the action of a HTML form.  Equally you might in a script language access the query-string part of a Universal Resource Locator to get parameters for what the script is to supply to the web page.  Even if you don't understand the meaning of those technical terms, you probably have seen when using a browser (in the box where a URL is entered) that sometimes the URL seen there has a query-string. You will have seen a question mark (?) followed by one or [separated by ampersand (&)] more '''name=value''' parameters.


== Case sensitivity ==
The GET approach to using the Cumulus general api works in this way indicating the start of a query-string with a question mark and using ampersands to separate names. The difference is that a tag name (or list of tag names) is used instead of a name=value parameter (or list of name=value parameters).  However, when the Cumulus api returns the values they will be in attribute=value format.  Therefore if (like example below) you are coding in JavaScript, what is returned is a JavaScript Object and you extract the values by specifying the Object name and the Attribute name. If that technical terminology confuses you, look at the example.


The tag_name in the general format above is case sensitive, so please type the tag name exactly as shown in the web tag columns in the tables below.
===Selecting values using GET===


The optional input parameters always use lower case, so please type them exactly as shown in the sections dealing with input parameters.
Suppose you want to get the values for the following three web tags:
 
# <#RCtemp>
The optional output parameters are case insensitive when used in Cumulus 1. But for Cumulus 2 and later, so this includes MX, the output parameters are case sensitive and also dependent on what other output formatters are being used if any, so please read the sections on output parameters and study the examples in the tables carefully.
# <#RChum>
 
# <#RCdew>
==Inconsistency of web tag names==
Then the URL with query-string to use is '''http: //localhost:8998/api/tags/process.json?rc&temp&hum&dew'''


Some tags are all lower-case, some are camel-case, and some start with a capital letter. Have a look yourself at just how much inconsistency is present in the names in the tables below. The great inconsistency in the naming, gives rise to a problem as it very easy to spell a tag_name incorrectly as you naturally expect there to be a standard pattern.
Obviously, if you have started MX with a port parameter like this:
<pre>sudo mono CumulusMX.exe -port 9999</pre>
then you change the 8998 port shown in the URL for the api to use the port you have selected e.g. '''http: //localhost:9999/api/tags/process.json?rc&temp&hum&dew'''


You will find yourself frequently having to refer to this article, if you decide to make your own Cumulus templates (see section below for more information). This applies whether those templates are for [[Customised templates|web pages]],  to implement [[Xml webtags|Extensible Mark-up Language files]],  or [[Php webtags|PHP Hypertext Pre-processor scripts]].


When Steve Loft introduced the first web tags as part of developing software for his own use, he did not create a naming standard to ensure consistency in the future. As he introduced further web tags at different times, the names used might be consistent amongst the ones introduced that day, but there was still no naming convention to ensure consistency with tags introduced previously or to help name future tags.
The first parameter is '''rc''' to indicate that the tags that follow are to use decimal points not decimal commas, which is how many script languages expect to see values.
Remember that in current version (and some earlier versions) of MX, the above three web tags are exactly same as:
# <#temp rc=y>
# <#hum rc=y>
# <#dew rc=y>


===Inconsistency for today, yesterday, this month, this year groups===
Since '''rc=y'''  can be applied to several web tags that don't appear in [[Webtags#No_Commas]] table, this shows how the api can access values without commas for all those web tags that report in real numbers and allow that output modifier.


It would be easier if all tags reporting parameters for today were consistent, let alone consistency in naming between tags for today and yesterday.  The tags for this year and this month were introduced in same release, so there is some consistency in how they were named then, but no standard to ensure future tags for this month and this year would be named the same way.
If you are using the api in a context where it does not matter if decimal commas or decimal points are in the api or for any tags that don't report in real numbers, simply omit the '''rc''' as first item, and just include tag names separated by ampersands.


===Inconsistency in use of "Y"===
=== JavaScript example ===


*The character "Y" might be included in a web tag to denote '''yesterday''', or it might denote ''this year''
Some people might feel the admin interface could be improved on some of its pages by showing additional information. It is possible from MX 3.7.0 to obtain extra information. 
*Where the Y is indicating '''yesterday''', it is sometimes a ''prefix'', sometimes a ''suffix''!


===Inconsistency in use of "T"===
I wanted to improve the log file editing pages, and that was partly by adding validation, and partly by changing the way the editing is done.  For the standard log file editor I wanted to achieve even more, I added a script to calculate (and recalculate after any edit) the derived fields from the source fields.  To make these calculations work for anyone, I needed to find out what units the Cumulus MX user is using. Before 3.7.0 release the snippet of script that obtained the units via various api calls was quite complex (I described above how the api returned lots of unwanted content), but with 3.7.0 my new api call was greatly simplified to what I show below. Please note my revised log file editing scripts did not make it into a public release, and it is only the units obtaining api that I am making available to public here.


*The newer web tags for '''today''' include a "T" as a suffix, the older ones do not. 
Here is the code (with the api call written using jQuery):
**The lack of a "T" in some today tags causes some confusion with all-time record tags as they have a similar naming structure to these older today web tags.  
<pre>/*   Some new variables connected with new api call (MX 3.7.0)  */
**This is particularly confusing and is why you must look up today, and all-time, tags in the tables in this article.
var tempLetter;  // C or F
*The time-stamp tags add a "T" to the corresponding web tag for the value, but in an inconsistent way:
var rainUnit; // mm or in
**the T is a prefix sometimes and  
var windUnit; // any units in style allowed by Cumulus
**the T is a suffix sometimes
/* The one extra api request included to obtain the units used for temperature, rainfall, and wind speed */
**This is particularly confusing and is why you must look up time-stamp tags in the tables in this article.
$.get('./api/tags/process.json?tempunitnodeg&rainunit&windunit', "limit=1", callUnits);
 
function callUnits(unitsObject)
===Choosing script variable names derived from tag names===
{
 
tempLetter = unitsObject.tempunitnodeg;
In the web tag to PHP variable scripts, I have posted, see [[Php_webtags#Minimised_Upload_size]], I have tried to introduce better consistency in the PHP variable names, so "T" is added as a suffix to all "today" variables for example. Some other script authors try to match the inconsistent web tag names, so their script variable names are also inconsistent.
rainUnit = unitsObject.rainunit;
 
windUnit = unitsObject.windunit;
== Optional Parameters ==
console.log("new api", tempLetter, rainUnit,windUnit);
 
}</pre>
=== Input modification Parameters ===
A little bit of explanation might help:
 
*JavaScript variables generally need to be declared first, I have used 3 separate line each starting with '''var''', but you can list several variables on one line using a comma to separate them
Most web tags do not require any input parameters. An input parameter is used where the same web tag can represent a value for a number of different past time instants. Each of those past time instants is represented by a different value for the input parameter. So a combination of web tag name and input parameter lets Cumulus to pick the value you want to see.
*In my script it is important to define these variables outside the function as I will explain later
 
*The jQuery get request takes the api URL as first parameter and the function to deal with the returned result as third parameter
There are currently only two types of tags where an input parameter is mandatory:
*The middle parameter is irrelevant in this context as only one object instance is returned, but if the qet was returning multiple results, "limit=1" would only return the first result
 
*The function takes as its sole parameter an Object (a JavaScript Object is a collection of properties), this is what is returned by the api, an object can be given any variable name
*The '''recent history tags''' where a separate value exists for potentially every [[#Recent_History|individual minute in last week]]. These tags need an input parameter specifying how many minutes ago is required. To save entering a very large number for minutes, an input parameter can combine days, hours, and minutes, ago using up to 3 input parameters as explained in linked section.
*In JavaScript if a variable is defined outside the function, then given a value inside the function, that value can be accessed by later code outside the function (in my case by code within the other functions for calculating each derived value)
*The [[#Monthly_All_Time_Records]] where a separate one exists for each particular month (of any year) need input parameter specifying which month. Again see the respective section for full details of input parameter (which is 1 for January to 12 for December, but 0 is also available with a special meaning).
*We are only interested in 3 of the '''property_name = property_value''' items in the Object.
*The JavaScript '''refinement''' syntax (starts with a dot) can be used to find the value for any parameter we name. We assign the variable already defined to the object and its refinement (that specifies the attribute we want).
*The console.log command simply outputs all the items in the list within the brackets into the browser console that in many browsers is displayed by selecting '''F12''' on the keyboard. I included this instead of the lengthy rest of my code that uses the units to do the various calculations correctly.


=== Output modification parameters ===
== "POST" approach ==


These are complex, they vary between Cumulus 1 and later flavours, and what output modifiers can be used varies between web tags.
The word "Post" in a computer environment means that the Hypertext Transfer Protocol (HTTP) used by the internet is being asked to transfer information enclosed in the body of the request message. Put slightly less technically in this approach you produce a text file with the details of what tags you want and send it to the api server.  I suppose it is a bit like sending an email, its header (subject, author, date sent) is easy to view, but you need to open it to see what text is in the body.


Consequently, output modifiers will be discussed in a later section headed [[#Output_.27format.27_Parameter]].  
You may have used POST as an attribute when defining the action of a HTML form. In that context the form is sent as the contents of a message to whatever web page is going to process the contents of that form.  


The options available include:
The post approach has a few advantages over get:
* changing date and/or time format,  
*The parameters are not shown in any query-string, so are not obvious to the person looking over your shoulder, nor do they appear in a history list of sites that the browser has visited.
* changing number of decimal places, and  
*If you fill out a form online, the post approach will be used as the content needs to be kept secure.
* removing decimal commas.
**The get approach may be seen when you are navigating through a web site, and a selection is being remembered.
*The POST approach can handle very long requests and return a lot of information.
**In contrast, a URL with query-string is restricted in total length (the restriction is dependent on a number of other factors, but might be at something like 1000 characters in total), so GET comes with a restriction on how many parameters can be specified.


== Cumulus Templates ==
See https://cumulus.hosiene.co.uk/viewtopic.php?p=145050#p145050 for post example


=== Using web tags in templates for creating HTML pages ===
=The Web Tags for Cumulus =


*You can create a template file that has a structure of HTML elements with Cumulus web tags to represent the information you want included.
Here follow tables indicating what web tags are available to be used, tables group them by the basic purpose of the tags listed.
*If you  [[Customised_templates#What_to_select_on_the_.27Files.27_tab_of_the_Internet_Settings_screen_within_the_.27Configuration.27_menu|ask Cumulus to process]] that template file, it will create a HTML page from the template, and during that file creation replace the tag with the current value of the item the tag represents.
*You also need to tell Cumulus that the resulting HTML file is to be uploaded to the internet (or copied to a local web server).


=== Using web tags in scripts ===
== System ==


*You can also use the tags within script, this might be a PHP script, or JavaScript either embedded in HTML, or in external files, to transfer the values (or the result of calculations based on those values) to your web server for further processing.
Special tags returning information about the Windows device hosting Cumulus 1.  
*As JavaScript can not understand a real number that has the integer and decimal parts separated by a comma, but your computer may be set to use that representation in standard tags, there are special versions of many tags to use in script - see [[#No_Commas|tags with commas removed]] section.
*Note that if a PHP or JavaScript file contains any Cumulus web tags then you must [[Customised_templates#What_to_select_on_the_.27Files.27_tab_of_the_Internet_Settings_screen_within_the_.27Configuration.27_menu|ask Cumulus to process]] the script file.
*JavaScript processing code can be embedded in a template that is already being processed into HTML. (This technique has been used  in the standard 'monthlyrecordT.htm' template).
*Alternatively embed a bit of JavaScript assignment code in HTML, that is already been processed, to convert the tags to a collection of string variables and use those variable names in any external script called from the HTML file. (This technique has been used in the standard 'gaugesT.htm' template).
*To use the value from a tag as an integer in JavaScript assigning code you need to use a
<pre>integer_variable_name=parseInt(string_variable_name,10)</pre> type conversion
*To use a value from a tag as a floating point number in JavaScript you need to use <pre>parseFloat(string_variable_name)</pre> otherwise you will find any attempt to add something to it results in a concatenation because JavaScript uses "+" for two purposes and concatenation takes precedence over arithmetic adding!
*Alternatively, in most script languages, apply ' * 1', i.e. multiply by one, to implicitly convert the tag from string to base 10 number.
*Another alternative is to add zero when a web tag is being assigned to a script variable, this is frequently used in scripts where the web tag being used is not available in all versions of Cumulus, because Cumulus does not implement the concept of null values and often zero is used when a true value is not available because that sensor is not installed for example. Adding 0 means that if the web tag is not recognised, the script is still able to give a variable in its language some value and won't fail because that variable is undefined. If the web tag is available, adding zero does not prevent the true value of that web tag being assigned to the variable.


== Web Tag Differences Between Cumulus 1 and MX builds ==
[[File:Badge vMx.png]]''If you are running MX, then most tags do not work.''
{{Version badge 1}}
This badge is used when the web tags listed in one of the tables are available in the final 1.9.4 release of Cumulus 1, but not in MX.  When Cumulus 1 is processing web tags, it tends to ignore any it cannot understand, so look for gaps in your web pages to find errors.


[[File:Badge vMx.png]]
{| class="wikitable" border="1"
Cumulus MX provides many, but not all web tags that were available in Cumulus 1. MX adds many more web tags, mostly in support of new weather stations or new sensors. This badge is used against web tags listed in one of the tables that are only available in MX. See [[#GENERAL_TIP|tip]] at top of page for how to check which web tags are available in your build.
|-
!style="width:150px" |Web tag_name
!style="width:150px" |Applicability
!style="width:600px" |Function
|-
|<#OsVersion>
|up to 1.9.4, and MX
|OS version, e.g. "Windows 7 x64 build 7600"


A combination of badges appears where certain aspects apply to Cumulus 1 or to MX. No information is given for Cumulus 2 as it is no longer available.
Please note this may not return the information you expect!
 
|-
When MX is processing web tags and finds one it cannot understand, a "*** web tag error - see MXdiags file ***" message will appear in the engine console, and the diagnostic file will include something like this, be aware a "token" parser is used to evaluate web tags:
|<#OsLanguage>
<pre>Web tag error
|Both leagacy and MX
Exception: i=8998 len=106297
|OS language, e.g. "English"
inputText.Length=106297
|-
token=<#daylightlength format=H></pre>
|<#SystemUpTime>
This particular error is that when you use a single output format character it does not have same meaning as when there are multiple characters, correct this particular web tag to:
|{{Version badge 1}}(not available on MX)
<pre><#daylightlength format=%H></pre>
|How long the system has been up, e.g. "8 hours 21 minutes"  
 
|-
Please note that where this article makes reference to other pages in the Wiki, the information shown there might be specific to Cumulus 1, as there are differences between the user interface for Cumulus 1 and MX flavours of this software, and the Wiki was originally written before MX existed, so not all pages have been updated.
|<#ProgramUpTime>
 
|all releases
=Output 'format' Parameter=
|How long Cumulus has been running, e.g. "7 hours 55 minutes"
 
|-
The majority, but not all, of web tags either can use an output format parameter or, in a few cases, really do need an output format parameter.
|<#CpuName>
 
|{{Version badge 1}}(not available on MX)
== Output Parameter Differences between Cumulus 1 and Cumulus MX (Cumulus 3) ==
|CPU type, e.g. "Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz"
 
|-
There are a number of differences between Cumulus 1 (C1) and Cumulus MX (MX). These nearly all involve times and dates, so the next section deals with this.
|<#CpuCount>
 
|{{Version badge 1}}(not available on MX)
 
|Number of processors, e.g. "4"
=== Output (format modifier) parameters for times and dates ===
 
Time/Date format codes are used in two places:
# As part of report names for NOAA style reports (see [[Cumulus.ini#Section:_NOAA]])
# As part of web-tags that report either times or dates or both a date and a time
From version 1.9.1 most web-tags  that report any form of time or date will accept an optional 'format' parameter, e.g. (Cumulus 1 only): <#YearTempHT format=hh:nn>.
 
This allows you to override the default display format for that item, using the format specifiers in the table below.
 
Although, in theory, you can specify date formatting to times, and vice versa, this will not always yield a sensible result. It is best to look at the default format (in most, but not all, cases this reveals whether date and time information are both available):
*The time-stamps for today, and yesterday, only contain time information, so only time-based format instructions should be applied to them. You can use date format parameters on (for example) <#metdate>, and <#metdateyesterday> and that may give you your desired date information to augment the time-stamps.
*Almanac times such as sun-rise, moon-rise, are also only times, and time-based format instructions can generally be applied to them.  However, be aware these are calculated as at midnight GMT and for some of your calendar days, the times may be reported (in default format) as '--' if for example the moon does not rise that day.
 
C1 can work with times in 14.24 format using a full stop ('.') to separate the figures, MX must have colon (':') between hour and minute numbers. But with both flavours you can choose whether 12-hour clock is used with am/pm (in lowercase or capitals) or the 24-hour clock is used. You can choose to include/exclude leading zero for hours. You can only report the hour if you don't care about the minutes, or only report the minutes if you don't need the hour. In most cases you can add seconds to the output, and either milliseconds or microseconds. This does not imply that Cumulus calculates everything every microsecond, in fact many are only calculated once a minute, but the flexibility is there for time outputs.
 
Some web tags contain dates, or both dates and times, and for these there is flexibility (apart from those with fixed format, these might have ISO, or another format indicator, in their tag name) as to how the date is output. Thus you can choose to include or exclude the year; you can represent month in letters or numbers, and you can vary the order in which elements of the date are shown.
 
The characters used to represent year, month, day, hour, minute, second, microsecond, do differ between C1 and MX. In Cumulus 1 we are able to use "m" or "M" for two different meanings (minutes or month) depending on context. Similarly, in MX the same character sometimes has two different meanings depending on context, but this applies to lots of characters and the context is whether the character is used on its own or with other characters. '''Sounds confusing?''' Well it is complicated.
 
==== Explanation ====
 
*Cumulus MX (when running on Windows) uses the '''.NET''' software.
*If Cumulus MX is running on Linux or Mac OS X, or any other device that uses UNIX derived operating system, then it uses '''Mono''' software for same purposes. (MONO is a operating system independent version of .NET, although they are developed independently, they have common origins). Please see the [[Cumulus MX]] article for more details of their differences and what will change in November 2020.
*The date and time format characters in Mono (and .NET) software framework are not exactly the same as the '''Delphi''' software framework ones that Cumulus 1 uses. 
*For Cumulus MX there are standard format codes (single characters) and custom format codes (combinations of characters, or single characters prefixed by %)
**The standard characters for dates and times are defined at [https://docs.microsoft.com/en-us/dotnet/standard/base-types/standard-date-and-time-format-strings standard-date-and-time-format-strings]
**The custom characters for dates and times are defined at [https://docs.microsoft.com/en-us/dotnet/standard/base-types/custom-date-and-time-format-strings custom-date-and-time-format-strings]
*In Cumulus MX the same character can have 4 different meanings depending on its case (capital letter or lower-case letter) and depending on whether it is on its own or not
**The case differences come about because Delphi is case-insensitive, while .NET and MONO are case sensitive.  Consequently, .NET (and MONO) can use upper and lower case for different items, but Delphi has to use different letters, ignoring case, for each item.
 
==== When it causes problems ====
 
This can cause problems when somebody moves from using Cumulus 1 (C1) to using MX. They need to revisit any templates or scripts where they use output modifiers to specify a date and/or time format. We have already explored a very simple impact of this for [[Webtags#The_format_used_for_naming|NOAA report naming]]. There we were only concerned about how to represent a month.
 
For web tags it is much more complicated, simply because it is not just month we may be representing, and we might require only one specifier (being careful whether we use a standard or custom modifier) or we might want to specify a combination of modifiers (and we might want to add a space character or other literals). It is difficult to summarise, but here are some potential issues:
* the reserved characters are different in C1 and MX (affecting use of literals like "on" and "at" that appear in many English time-stamps)
* MX introduces the concept of escaping characters (a '''\''' placed before a character can be either a control sequence or an instruction to display the character)
* MX is inconsistent e.g. '''format=d''' gives a different result depending on the tag it is applied to (e.g. the script conditional ''''<#metdateyesterday format=d>' == '<#yesterday format=d)>''''  will never be equal as the LHS returns a full date and the right hand side returns day of month only)
* in MX space in some cases may need to be within the single quotes containing other literals (as in MX space can change the interpretation of a modifier character).
 
'''Confused even more now?''' I'm not surprised, but maybe some examples will help before we actually list the available modifiers.
 
==== Examples ====
 
*Examples related to case selection
*#[[File:badge v1.png]] In Delphi, "nn" means "minutes" for Cumulus 1, [[File:Badge vMx.png]]but "minutes" is "mm" for .NET or MONO in Cumulus MX.
*# The hour in 24-hour format with leading zero, in non case sensitive Delphi (Cumulus 1) 'HH' or 'hh' would be treated as same, but in .NET or MONO it must be "HH" (Cumulus MX).
*# The hour in 24-hour format without leading zero, in non case sensitive Delphi (Cumulus 1) 'H' or 'h' would be treated as same, but in .NET or MONO it must be "%H" (Cumulus MX).
*# For 12-hour specifiers, please see the table, as this is far more complicated.
*[[File:Badge vMx.png]]You might be put off by references within .NET and MONO (Cumulus MX) to single/standard characters and custom modifiers, the following 3 examples may add clarity:
*#For example, ''<#MonthTempHD format="d">'' is a single character format modifier, therefore the 'd' acts as a standard modifier, and causes for a date of 22 July 2014 for the highest temperature in the month to be returned in the standard short date format e.g. '22/07/2014' (exact contents for any one date vary by locale).
*#Similarly, ''<#MonthTempHD format="M">'' is a single character format modifier and therefore the 'M' acts as a standard modifier and causes the date for the highest temperature in the month to be returned in the standard day and month format e.g. '22 July' (exact contents for any one date vary by locale).
*#Whilst ''<#metdate format="d M">'' is not a single character format modifier and therefore both the 'd' and the 'M' are interpreted as custom modifiers and cause the current date to be returned as a digit(s) for the day and a digit(s) month (in a without leading zeroes format) e.g. '6 7' would be returned for 6 July.
*#Alternatively,  ''<#MonthTempHD format="%d">'' is NOT a single character format modifier, therefore the 'd' acts as a custom modifier, and causes a date of 22 July 2014 for the highest temperature in the month to be returned as the day of the month only '22' in all locales.
*#Similarly, ''<#MonthTempHD format="%M">'' is NOT a single character format modifier and therefore the 'M' acts as a custom modifier and causes the same date for the highest temperature in the month to be returned as the month number '7'.
 
In both Cumulus 1 and MX if you want a space character within your output, the output specifiers must be enclosed in double quotes. If that space character is next to a non modifier (e.g. around word "at") then the single quote needing to surround the at should be widened to include the spaces in MX, but Cumulus 1 does not care if single quotes excluded spaces. However, with MX, single quotes enclose multiple characters, but there is an alternative way to deal with some single verbatim characters to cover next.
 
So let us compare these two alternative ways that MONO and .NET  escape any characters that are not being used as format specifiers.
* In [[File:badge v1.png]]Delphi you can put the 'verbatim' characters inside single quotes (Cumulus 1); this is often used to (in English) include words like ' on ' and ' at ' in the formatted output.
*in [[File:Badge vMx.png]].NET or MONO you can still use single quotes (as mentioned above extended to include adjacent spaces),
** but alternatively you can escape each verbatim character with a backslash as prefix (Cumulus MX).
* You may need to use both single quotes and back slashes in some format specifiers, depending whether the characters you want to include can be interpreted as control characters (yes, backslash is also used to escape control characters, so backslash will NOT work for some characters such as those in "on" and "at" [\n will produce new line not the letter n, \t will produce a tab not the letter t]), consequently for some characters you must use the literal approach to include them in your format.
 
=== List of allowed modifiers for output format parameters ===
Note for Cumulus 1 - where lower (or upper, for easier comparison with MX) case shown, because Delphi is case insensitive, upper (or lower) case (in some cases, indicated by use of curved brackets) could be used instead (exceptions: a/p, ampm, am/pm, Am/Pm, AM/PM, A/P, AMPM etc display as input).
 
[[File:Badge vMx.png]]Remember that most single character format specifiers have a different meaning to when the same letter appears in a multi-character format. The '''%''' shown in front of nearly every single character specifier in the table is not needed if that character is combined with other characters.
 
 
==== Forum reference ====
 
Steve Loft published a table showing comparison between output date modifiers for Cumulus 1 and MX at [https://cumulus.hosiene.co.uk/viewtopic.php?f=39&t=17888 Cumulus MX forum].  The table there was based  on the table that was originally here for just Cumulus 1.
 
The subsequent comments in the forum suggested his layout got people confused. Most of that confusion came in two circumstances:
*When someone wanted to use one date or time modifier on its own
*When someone who had been using Cumulus 1 swapped to MX and wanted to replace a combination of output modifier characters
 
That all comes from the fact that when a MX modifier consists of a single character it can mean something different to when it appears with other characters.  In Cumulus 1, "m" or "M" meant something different when it was combined with "H" or "h" (when it represented minutes), but in all other contexts it represented month. But for Cumulus 1, there is no other case where it matters what context a modifier is put in by the use of other modifiers, and no other modifier takes more than one meaning.
 
In MX it is much more complicated, to take a few examples "D", "H", "M" represent different items on their own to what they represent when combined with other characters.  That other character can be as simple as a space or a "%" which modify the meaning of the character. So my modification of the table below is with the intention of demonstrating what characters mean when they are on their own and what they represent in the context of being with other characters. Looking at the table you can see "G" is used on its own because it represents a full date-time specifier. "D" is similarly used on its own represents the long date format. If we only want the day of month number we must use "%d" to avoid the meaning of short date format that "d" on its own represents. If we want the typical Cumulus date-stamp of day of month number and month "d M" and "M" will both work because "M" has a different meaning on its own and with another modifier.
 
==== My Revised Table of Time and Date Output Modifiers ====
 
In some rows of this table, square brackets [] indicate optional items, they are included just to make it clearer how items can be combined in a single output parameter.
{| class="wikitable" border="1"
|-
|-
!style="width:150px" | {{Version badge 1}}Delphi Specifier for Cumulus 1.9.x
|<#MemoryStatus>
!style="width:150px" | [[File:Badge vMx.png]]Mono/.NET Specifier for Cumulus MX
|{{Version badge 1}}(not available on MX)
!style="width:600px" | Displays
|Free and total system RAM, e.g. "4619/8191 MB (free/total)"
!style="width:600px" | Example
|-
|-
|c
|<#DisplayMode>
|G  (as single character format)
|{{Version badge 1}}(not available on MX)
|Displays the date using the format given by the Short Date format, followed by the time using the format given by the Long Time format. The time is not displayed in Cumulus 1 if the date-time value indicates midnight precisely.
|Screen display mode, e.g. "1680x1050, 32 bit"
|'22/03/2019 09:47:25' produced by {{Version badge 1}}<#time format=c>[[File:Badge vMx.png]]<#time format=G>
|-
|-
|d
|<#AllocatedMemory>
|%d
|{{Version badge 1}}(not available on MX)
|Displays the day as a number without a leading zero (1-31). [[File:Badge vMx.png]]Note that Cumulus MX requires a ' ' (space), '%' or other modifier to be included, as 'd' on its own returns full 'short date').
|Amount of memory allocated to Cumulus, e.g. "18.76 MB"
|27 produced by {{Version badge 1}}<#metdate format="d">[[File:Badge vMx.png]]<#metdate format="%d">
|-
|-
|dd
|<#DiskSize>
|dd
|{{Version badge 1}}(not available on MX)
|Displays the day as a number with a leading zero (01-31).
|Size of disk on which Cumulus is running, e.g. "931.51 GB"  
|07 produced by <#metdate format="dd">
|-
|-
|ddd
|<#DiskFree>
|ddd
|{{Version badge 1}}(not available on MX)
|Displays the day as an abbreviation (Sun-Sat) using the strings appropriate to the Locale.
|Free space on disk on which Cumulus is running, e.g. "515.36 GB"
|'Wed' produced by <#metdate format="ddd"> (English locale)
|}
 
== Miscellaneous ==
 
All tags are available in all flavours, as far as I know, although ''their output might vary'', and which input/output parameters they permit might vary between Cumulus 1 and MX.
 
{| class="wikitable" border="1"
|-
|-
|dddd
!style="width:150px" |Web tag_name
|dddd
!style="width:900px" | Function
|Displays the day as a full name (Sunday-Saturday) using the strings appropriate to the Locale.
|'Friday' produced by <#metdate format="dddd"> (English locale)
|-
|-
|ddddd
|<#LatestError>
|d (as single character format)
|Displays the last error from the Cumulus 1 error log. (The value is cleared when you click the error light in Cumulus 1).<br />
|{{Version badge 1}}Cumulus 1.x.y: Displays the date using the format given by the Short Date format.   [[File:Badge vMx.png]]This MX parameter (when on its own) displays inconsistent behaviour as its effect depends on the tag name with which it is used (see examples).
Note: This tag displays ''all'' errors, even if they do not cause the error light to flash in Cumulus 1. Although this tag and the next 3 are in MX, none of them are actually used (as at April 2020).
|e.g. '22/03/2019' (British Locale) produced by {{Version badge 1}}<#metdate format=dddd>
[[File:Badge vMx.png]]<#metdateyesterday format=d> ''but not'' <#yesterday=d> which would return just '22'
|-
|-
|dddddd
|<#LatestErrorDate>
|D  (as single character format)
|The date of the latest error logged to the error log window, using the system short date format. Gives dashes when latest error is reset
|Displays the date using the format given by the Long Date format.  [[File:Badge vMx.png]]The MX parameter cannot be combined with any other parameters.
|e.g. '22 March 2020' (British Locale)
|-
|-
|M (or ''m'')
|<#LatestErrorTime>
|%M
|The time of the latest error logged to the error log window, using the system short time format. Gives dashes when latest error is reset
|Displays the month as a number without a leading zero (1-12).
*{{Version badge 1}}Cumulus 1.x.y:If the 'M' or 'm' specifier immediately follows an h, hh, HH, or H specifier, the minute rather than the month is displayed.
*[[File:Badge vMx.png]]Cumulus MX: Note that including a ' ' (space) or '%' before the M makes it a custom modifier e.g. '7' is returned for July as any initial zero is suppressed. ('M' on its own returns both Month and Day according to local format e.g. 22 July).
|2
|-
|-
|MM (or ''mm'')
|<#ErrorLight>
|MM
|1 if the 'error' light is flashing, 0 if not
|Displays the month as a number with a leading zero (01-12).
*{{Version badge 1}}Cumulus 1.x.y:If the 'm' or 'M' specifier immediately follows an h, H, HH, or hh specifier, the minute rather than the month is displayed.
|'03' produced by <#LastDataReadT format=MM>
|-
|-
|MMM (or ''mmm'')
|<#version>
|MMM
|The version of Cumulus in use e.g. '1.9.4' or '3.4.1'
|Displays the month as an abbreviation (Jan-Dec) using the strings appropriate to the Locale.produced by <#metdate format="MM">
|'Jun' produced by <#metdate format="MMM"> (English locale)
|-
|-
|MMMM (or ''mmmm'')
|<#build>
|MMMM
|The build of Cumulus in use e.g. '10992' for latest Cumulus 1 patch
|Displays the month as a full name (January-December) using the strings appropriate to the Locale.
|'June' produced by <#metdate format="MMMM"> (English locale)
|-
|yy
|yy
|Displays the year as a two-digit number (00-99).
|19 produced by <#LastDataReadT format=yy>
|-
|yyyy
|yyyy
|Displays the year as a four-digit number (0000-9999).
|2019 produced by <#LastDataReadT format=yyyy>
|-
|h [''AM/PM'']
|%h [''tt'']
|Displays the hour (12 hour clock) without a leading zero (1-12) [optionally in combination with AM/PM]. What "tt" produces depends on locale settings for your device, it might be capitals or it might be lower case (in Windows use Control Panel, not Settings app, to get to these regional additional settings).
{{Version badge 1}}For Cumulus 1 the formats for am/pm depend on the case in which you type the parameter as shown later in this table


[[File:Badge vMx.png]]Note that including a ' ' (space) or '%' before the "h" makes it a custom modifier, that is not needed if the " tt" follows, as multiple parameters are always custom modifiers
(Cumulus MX is under development so new builds are released frequently)
|-
|-
|h:mm (or ''h:nn'') [''AM/PM'']
|<#NewBuildAvailable>
|h:mm [''tt'']
|'''Only available from release 3.7.0''' onwards, it is checked on start-up and once a day thereafter at a random time
|Displays the hour (12 hour clock) without a leading zero (1-12) followed by 2 digit minutes [optionally in combination with AM/PM whose case varies as explained in previous entry].
*Returns a boolean value
{{Version badge 1}}For Cumulus 1, the minutes can be represented by 'mm' only when appearing in combination with 'h'
**0 - MX running the latest build available
|'10:27 am' produced by {{Version badge 1}} <#LastDataReadT format="h:nn am/pm">[[File:Badge vMx.png]] <#LastDataReadT format="h:mm tt">
**1 - MX is running an earlier build that the latest public release
|-
|H (or ''H'')
|%H
|Displays the hour using 24 hour clock without a leading zero (0-23). [[File:Badge vMx.png]]Note that including a ' ' (space) or '%' before the "H" makes it a custom modifier, needed because H is on its own.
|7 produced by {{Version badge 1}}<#daylength format=H>
[[File:Badge vMx.png]]<#daylength format=%H>
|-
|-
|H:mm (or ''H:nn'')
|<#NewBuildNumber>
|H:mm
|'''Only available from release 3.7.0''' onwards, it is checked on start-up and once a day thereafter at a random time
|Displays the hour using 24 hour clock without a leading zero (0-23) followed by 2 digit minutes. [[File:Badge vMx.png]]Note that %, of previous example, is not needed when H is not on its own.
 
|'7:27' produced by <#LastDataReadT format="H:mm">
Displays the latest public release build number - eg. b3089
|-
|-
|HH (or ''hh'')
|<#realtimeinterval>
|HH
|The real time update interval in seconds (integer)
|Displays the hour using 24 hour clock with a leading zero (00-23).
|'06' or 19 produced by <#LastDataReadT format=HH>
|-
|-
|hh (''am/pm'')
|<#interval>
|hh [''tt'']
|The web site update interval in minutes (integer)
|Displays the hour (12 hour clock) with a leading zero (01-12) [optionally in combination with am/pm].
{{Version badge 1}}For Cumulus 1 the case output for the optional 'am/pm' depends on the case used for that parameter as shown later in this table
[[File:Badge vMx.png]] For MX, the optional 'tt' displays the contents of the device locale setting for AM string for midnight until any hour before noon, and the contents of the PM string for noon or any hour after noon before midnight
|'07 am' produced by {{Version badge 1}} <#LastDataReadT format="hh am/pm">[[File:Badge vMx.png]] <#LastDataReadT format="hh tt">
|-
|-
|hh:mm (or ''hh:nn'' or 'HH:NN') [''am/pm'']
|<#rollovertime>
|hh:mm [''tt'']
|The time that the logs rollover to the next day: will always return one of these: 'Midnight', '9 am' or '10 am'
|Displays the hour (12 hour clock) with a leading zero (01-12) followed by 2 digit minutes [optionally in combination with am/pm].
 
{{Version badge 1}}For Cumulus 1, the minutes can be represented by 'mm' only when in combination with 'h', in other contexts 'mm' is interpreted as month number, and the case output for am/pm depends on the case used for that parameter as shown later in this table. As Cumulus 1 is case insensitive there are variants with capital letters available.
This is the end of the meteorological day, so if during Daylight Saving Time rolover is at "10 am", then on the day DST ends it will return to "9 am" ensuring every meteorological day is exactly 24 hours long. If the time is "Midnight" (or during DST it is "9 am"), then days will be 23 or 25 hours long just on day clocks change, 24 hours otherwise.
[[File:Badge vMx.png]] For MX, the optional 'tt' displays the contents of the device locale setting for AM string for midnight until any hour before noon, and the contents of the PM string for noon or any hour after noon before midnight
|'8:27 am' produced by {{Version badge 1}} <#LastDataReadT format="h:nn am/pm">[[File:Badge vMx.png]] <#LastDataReadT format="h:mm tt">
|-
|-
|n
|<#update>
|%m
|The date and time of the last web site update. The default format of the output depends on your locale settings.
|Displays the minute without a leading zero (0-59). [[File:Badge vMx.png]] As other examples show, the % is only needed when "m" is on its own.
|7 produced by {{Version badge 1}}<#daylength format=n>[[File:Badge vMx.png]]<#daylength format=m>
|-
|-
|nn
|<#LastDataReadT>
|mm
|The date/time data was last read from the station. The default format of the output depends on your locale settings.
|Displays the minute with a leading zero (00-59).  
|'07' produced by {{Version badge 1}}<#daylength format=nn>[[File:Badge vMx.png]]<#daylength format=mm>
|-
|-
|s
|<#stationtype>
|%s
|The weather station [https://cumuluswiki.org/a/Cumulus.ini#Section:_Station model] description (you choose what text appears for this on 'Display' settings screen within Configuration menu - the field is at the bottom left of that screen).
|Displays the second without a leading zero (0-59). [[File:Badge vMx.png]] As other examples show, the % is recommended when "s" is on its own, although I have not found any alternative meaning for "s" on its own.
| 9
|-
|-
|ss
|<#latitude>
|ss
|The station [http://en.wikipedia.org/wiki/Latitude latitude] (as you entered during setup).
|Displays the second with a leading zero (00-59).
Supports an optional 'dp' parameter, if supplied, instead of the usual web-encoded text format with degrees/minutes/seconds, the result is in decimal degrees to the specified number of decimal places. E.g<br />
|'06' or 19 produced by <#LastDataReadT format=ss>
<#latitude> gives "N&nbsp;59& deg;&amp;nbsp;14&amp;#39;&amp;nbsp;33&amp;quot;" for N 59 14 33<br />
|-
<#latitude dp=5> gives "59.24250"
|z
|FFF
|Displays the millisecond without a leading zero (Cumulus 1: displays 0-999, Cumulus MX: displays either nothing, or displays 1-999, so don't write any code that assumes the MX output is numeric).  


Note that the system clock in non-current versions of Windows only has precision to 15 ms, so don't use this modifier if your Cumulus is running on an old version of Windows.
If the "dp" parameter is supplied, then supplying "rc=y" in addition will cause any decimal comma to be converted to a decimal point.
|
|-
|-
|(not available)
|<#longitude>
|ff (or ''f'')
|The station [http://en.wikipedia.org/wiki/Longitude longitude]  (as you entered during setup). Supports an optional 'dp' and 'rc' parameters as per the latitude tag.
|Displays hundredths of a second (or tenths) with leading zero(s)
|
|-
|-
|zzz
|<#altitude>
|fff
|The station [http://en.wikipedia.org/wiki/Altitude altitude] value (web tag outputs web encoded format containing figure, '&amp;nbsp;' and units) in either feet or metres just as you entered during setup (so it is more complex to extract number for script arithmetic); e.g. '123&amp;nbsp;m'
|Displays the millisecond with a leading zero (000-999). Note that the system clock in some versions of Windows only has precision to 15 ms, so requesting thousandths of a second may not return anything useful.
 
[[File:Badge vMx.png]]The 'fff' modifier in MX can actually be extended to 'ffffff' for output to a millionth of a second!
| 09:47:25.000' produced by {{Version badge 1}}<#time format=hh:nn:ss.zzz>[[File:Badge vMx.png]]<#time format=hh:mm:ss.fff>
|-
|-
|(not available)
|<#location>
| zzz
|The station location (as you entered during setup)
|Displays the offset of any time from UTC in hours and minutes 
| e.g.-07:00
|-
|-
|(not available)
|<#longlocation>
|%K
|Longer description of the station location (as you entered during setup)
|Effectively another way of including time zone as per zzz example, but it can only be used for times not in UTC (if I understand correctly)
|
|-
|-
|t
|<#forum>
|%t
|URL of the forum (as you entered during setup)
|Displays the time using the Short Time format. [[File:Badge vMx.png]]Remember that 't' combined with other specifiers (or preceded by space or '%') has a different meaning - see below.
For Cumulus 1, this defaults to a Sandaysoft URL that is no longer available, for MX this defaults to the current support forum (web server site hosted by "Freddie")
| '09:47' produced by <#LastDataReadT format=t> (might not use colon in your locale) for both flavours of Cumulus
|-
|-
|TT
|<#webcam>
|T  (as single character format)
|URL of the webcam (as you entered during setup). Default is blank. Can be used to link to any other web page that you host (Cumulus does not verify that it is a web can, that is just a label, and the label can be changed on each standard web page individually)
|Displays the time using the Long Time format. [[File:Badge vMx.png]] Note that this is a full time specifier and "T" is on its own as we are using a single character format.
|'09:47:56'  (might not use colon in your locale) produced by {{Version badge 1}}<#LastDataReadT format=TT> [[File:Badge vMx.png]]<#LastDataReadT format=T>
|-
|-
|am/pm or Am/Pm or AM/PM
|<#graphperiod>
|tt
|The number of hours displayed by the graphs, as set using '''Configuration''' menu, ''Display'' settings screen 'Detailed Chart Period'  
|{{Version badge 1}}Uses the 12-hour clock for the preceding h or H specifier, and displays 'am' for any hour from midnight until just before noon, and 'pm' for any hour from noon onwards. The am/pm specifier for Cumulus 1 can use lower, upper, or mixed case, and the result is displayed accordingly.
 
[[File:Badge vMx.png]] For MX, 'tt' displays the contents of the device locale setting for AM string for midnight until any hour before noon, and the contents of the PM string for noon or any hour after noon before midnight, so whether it displays in capitals or lower case is determined by the locale settings, not the case of "tt".
| {Version badge 1}} 'am' produced by <#LastDataReadT format=am/pm>, 'AM' produced by <#LastDataReadT format=AM/PM>
|-
|-
|h a/p
|<#dailygraphperiod>
|h t
|The number of days displayed by the graphs, as set using '''Configuration''' menu, ''Display'' settings screen 'Daily Chart Period' (available from build 1098)
|Uses the 12-hour clock for the preceding h or H specifier, and displays 'a' for any hour from midnight until before noon, and 'p' for noon or any hour after noon.
{{Version badge 1} The a/p specifier can use lower, upper, or mixed case, and the result is displayed accordingly.
 
[[File:Badge vMx.png]]whether it displays the "a" or "p" in capitals or lower case is determined by the locale settings, not the case of "t".
| see previous example
|-
|-
|ampm
|<#LatestNOAAMonthlyReport>
|(see above for 12 hour formats)
|Gives file name of latest auto-saved NOAA monthly report
|This displays the contents of the device locale setting for AM string for midnight until any hour before noon, and the contents of the PM string for noon or any hour after noon before midnight.
{{Version badge 1}Uses the 12-hour clock for the preceding h or H specifier
| see previous examples
|-
|-
|/
|<#LatestNOAAYearlyReport>
|/
|Gives file name of latest auto-saved NOAA yearly report
|Displays the date separator character given by the Date Separator. It might not display a slash.
| '/' for typical British locale
|-
|:
|:
|Displays the time separator character given by the Time Separator. With Cumulus 1, this might not display a colon.
 
[[File:Badge vMx.png]]Note that by default Cumulus MX expects a locale to use ":" for any time separator.
|':' for British locale
|-
|'xy'
|'xy' or ''\x\y''
|Characters enclosed in single quotation marks are displayed as such, and do not affect formatting.
 
[[File:Badge vMx.png]]In MX each character to be displayed as it was typed can be prefixed by a backslash. Also remember that any spaces in a MX modifier might need to be within single quotes as space is also used to change what a modifier represents. I told you MX modifiers were more complicated!
|Hyphens are added in this PHP language example  '<#LastDataReadT format=yyyy>'.'-'.'<#LastDataReadT format=MM>'.'-'.'<#LastDataReadT format="dd">'
|}
|}


==== Using HTML tags within format parameters (available in MX only) ====
==Units==


'''Example using a class to change the look of part of the output'''
Apply to Cumulus 1 and MX, no optional input nor output parameters.
 
{| class="wikitable" border="1"
<pre><#TapptempH format="dd'&nbsp;'MMM'&nbsp;'yyyy'<span class=\'xx\'> at 'HH:mm'</span>'"></pre>
|-
the output from this will look like ''04&nbsp;Dec&nbsp;2018<span class='xx'> at 10:12</span>''
!style="width:150px" | Web tag_name
 
!style="width:600px" | Function
'''Note where the quotes are, and where you need to use '\' escape characters'''.
|-
 
|<#tempunit>
'''Example using HTML tags'''
|Unit of temperature being used (Set in Cumulus as [http://en.wikipedia.org/wiki/Centigrade Celsius] or [http://en.wikipedia.org/wiki/Fahrenheit Fahrenheit]) values "&amp;deg;C" or "&amp;deg;F"
|-
|<#tempunitnodeg>
|The temperature units being used, without a degree symbol, i.e. "F" or "C"
|-
|<#pressunit>
|Unit of measure for pressure. Possible values: "mb", "hPa", "in"
|-
|<#rainunit>
|Unit of measure for rain fall. Possible values: "mm" or "inches"
|-
|<#windunit>
|Unit of measure for wind speed. Possible values: "m/s", "mph", "km/h", "kts"
|-
|<#windrununit>
|Unit of measure for wind run (distance). Possible values: "km", "miles", "km", "nm" (for wind speeds in m/s, mph, km/h, kts)
|-
|<#cloudbaseunit>
|The units used for cloudbase value. Possible values:  "ft" or "m"
|}


<pre><#RecentTS d=2 format="h:mm'&nbsp;'tt'<small>on' d/M/yyyy'</small>'"></pre>
==Date & Time==
This puts the date in a smaller font than the time
Both Cumulus 1 and MX support all of these, except where marked as MX only, most of these web tags can be used with output parameters.
 
{| class="wikitable" border="1"
=== Output (format modifier) parameters for decimal places ===
|-
 
!style="width:150px" |Web tag_name
 
!style="width:600px" | Function
Cumulus 1 allows use of <tt>dp=n</tt> modifier (where n represents desired number of decimal places for latitude and longitude e.g. <#latitude dp=5> gives "59.24250". This is also available in MX.
|-
MX makes much more usage of these '''dp''' parameters. For example in the moon tags  <#MoonAge> gives "11" but <#MoonAge dp=3> gives "11.234"  
|<#date>
 
|The current date - format depends on locale you use to run Cumulus
*<tt>dp=i</tt> is used for both Cumulus 1 and MX. The value '''i''' following the attribute '''dp''' is an integer, how many decimal places you want for the output you see. Only available for a limited range of web tags (latitude and longitude, plus in MX <#MoonPercent> and <#MoonPercentAbs>).
|-
*<tt>tc=y</tt> is a new parameter only in MX, the attribute '''tc''' takes the value 'y' to remove decimal places by truncation instead of using <tt>dp=0</tt> which would round to nearest integer. e.g. <#MoonAge tc=y>. At present not available in any other web tags.
|<#metdate>
 
|The current meteorological date. The default format depends on the locale you use to run Cumulus
=== Output (format modifier) indicating remove commas ===
*If you use midnight rollover, this returns same date as <#date> (above), but with a different default format.
*If using a 9am/10am rollover:
**After rollover time on current calendar date,  this is same as <#date>, but with a different default format.
**Between midnight and 9am/10am the <#metdate> will return the date associated with previous calendar day, but will still return current time 


"rc=y" is a '''new parameter for MX''', the attribute '''rc''' takes the value 'y' to replace any commas defined by the locale with full stops to separate integer and decimal parts of the output value. It was initially only implemented on a few new web tags (#MoonPercent, #MoonPercentAbs, #MoonAge) for MX versions up to and including 3.5.3. From version 3.6.6 only can all web tags that can output real numbers can now use alternative syntax of <tt><#tag_name rc=y></tt> to replace all commas in the output by a full stop (don't worry, MX does not use a comma for separating off thousands, so it is the decimal comma that becomes a decimal full stop like character when this remove comma specifier is used.
{{Version badge 1}}Can be used with relevant format parameters to [[Customised templates|customise]] '''todayT.htm''' template page to display current meteorological day, to customise '''thismonthT.htm''' template page to display meteorological month, and to customise '''thisyearT.htm''' template page to display correct meteorological year. This will be particularly useful on first and last day of month/year when rollover happens at 9 (or 10) a.m. and the month (and maybe year) is different before and after rollover.


[[File:Badge vMx.png]] Earlier MX releases provide a similar web template set, so these can be customised in same way as for legacy Cumulus above (but note capital "M" must be used for any month formatting). From release 3.10.1 the supplied web pages are web server based, there are no web templates to customise, and the supplied '''.json files''' do not include any meteorological date functionality.
|-
|<#timeUTC>
|The current UTC date/time rather than local date/time.  Example result (actual format depends on locale settings): 18:30 on 30 December 2009. If you want the local date and time, use next tag (below).
|-
|<#time>
|The current time and date. Example result (actual format depends on locale settings): 18:30 on 30 December 2009.  If you simply wish the time, use next tag (below).
|-
|<#timehhmmss>
|The current time (without date). Example format: 18:30:27. You can use output format specifiers to change the way the time is output, but any date specifiers are ignored.
|-
|<#minute>
|The current time, just the minutes. Example format: 07
|-
|<#hour>
|The current time, just the hour. Example format: 07
|-
|<#day>
| The current day as a 2-digit number. Example format: 07 
|-
|<#dayname>
| The current day as a word.  For example, Monday  (actual format depends on locale settings)
|-
|<#shortdayname>
| The current day as a shortened word. Example format: Mon
|-
|<#month>
|The current month as a 2-digit number. Example format: 07
|-
|<#monthname>
|The current month as a word. Example format: July
|-
|<#shortmonthname>
|The current month as a shortened word. Example format: Jul
|-
|<#year>
|The current year as a 4-digit number. Example format: 2009
|-
|<#shortyear>
|The current year as a 2-digit number. Example format: 09
|-
|<#rollovertime>
|The time that the logs rollover to the next day: 'Midnight', '9 am' or '10 am'


Why would you want to remove decimal commas?  Well because the JavaScript language cannot understand decimal commas, and MX has several scripts written in this language, equally some third party alternative web pages rely on ajax to update them (and Ajax uses JavaScript).
PHP code example for testing whether before or after rollover given in next entry.
 
|-
== Additional text in output format parameters ==
|<#metdateyesterday>
 
|The previous meteorological date.  The default format depends on the locale you use to run Cumulus
You should put anything that is additional, to the defined format modifier specification below, into single quotation marks to prevent it being interpreted as a date or time format modifier:
*If you use midnight rollover, this returns same date as <#date>, but with a different default format.
 
*If using a 9am/10am rollover:
#For example, the word "on" contains the character "n", which for Cumulus versions 1.9.1 to 1.9.4 will be interpreted as a time format modifier unless you put it into single quotation marks. Example of valid Cumulus 1 syntax: <#TtempH format="'at' hh: mm 'on' dd / mm / yyyy">.
**After rollover time on current calendar date,  this is same as <#yesterday> (below), but with a different default format.
#You can include HTML tags (but they cannot have any attributes because both single and double quote characters have defined meanings) and special characters as quoted text within the 'format' parameter.<br> Example of valid syntax: <#TapptempH format="'at 'h:nn'&nbsp;'am/pm '&lt;small&gt;on' d/m/yyyy'&lt;/small&gt;'">.
**Between midnight and 9am/10am the date output by <#metdateyesterday> will be the calendar day before that returned by <#yesterday>, but the time returned is actual local time.   
 
{{Version badge 1}}'''Note for Cumulus 1 -  if your format has any spaces in it''', you must enclose the whole format parameter value in double quotes, for example (Cumulus 1.9.x): <#YearTempHT format="hh nn">. Consequently, you cannot include double quote characters in any other position (see [[Php_webtags#Web_tag_Complications| here for work-around]]).
 
[[File:Badge vMx.png]]Note for MX - you can use single quotation marks round spaces and text (e.g. ' on '), but you can also use '\' as escape character (e.g. for 'on' use '''\o\n'''). However for 'at' the only alternative is '''\a't''''  because the character t has another meaning and escape followed by a "t" i.e. "\t" becomes a tab!
 
 
 
=The web tag application programming interface=
 
[[File:Badge vMx.png]] Available from version 3.7.0 (build 3089) released 28 July 2020. It was proposed in January 2015, see Steve Loft [https://cumulus.hosiene.co.uk/viewtopic.php?p=101496#p101496 plan to add a call where you supply a list of items (probably web tag names), and you get back the equivalent data].
 
== Where to use ==
 
This is meant for services either on the same computer as Cumulus or on your local network. It is not secure, and should not be available, nor requested, via any external network or the internet.
 
The [[MX Administrative Interface]] uses some application programming interface (api) calls to obtain the data each web page in that interface needs, and another api to return the results of any edit made. If you wanted your '''CumulusMX/interface/todayyest.html''' web page to include something else (e.g. snow falling/lying/depth) you would edit that HTML page to have the extra sub-table you want (you cannot extend the existing rainfall table as that is dynamically created by existing api) and you would edit the associated JavaScript file '''CumulusMX/interface/js/todayyest.js''' to add a new api call seeking snowdepth, snowfalling, snowlying tags for today (unfortunately there are no tags for yesterday's snow) and to place the returned values into your new sub-table (probably using jQuery to make it easy). In a similar way, you could add anything where today and yesterday tags are available such as UV Index.
 
In earlier versions of Cumulus if you wanted to make use of values processed by Cumulus, you wrote a script file referencing the web tags you wanted to use, and let Cumulus process that file at an interval set in the settings, then you had to write something to process the results at the relevant interval. Now if you are running other software on your device that runs MX (or a computer or other device linked directly on your personal network), you can request web tags values on demand via an application programming interface (api hereafter) and don't need to worry about any timing issues.  
 
Obviously each api request creates a processing overhead on Cumulus so use this feature wisely (minimise the information you request and minimise the frequency of requesting it). You can use it for extra current information, but in that usage you might need to repeat the call. Consequently, maybe it is more likely that the api will be used to request information that does not keep changing, such as what units are being used for temperature, rainfall, and wind speed; or perhaps daily, monthly, or yearly, summary figures.
 
Each admin interface web page uses api techniques for all the information it needs. Some api calls are repeated with AJAX requesting updates for the weather information on a frequent basis, but each page has another api request that is issued just once for the version and build being used.  To my mind, the design of '''CumulusMX/interface/todayyest.html''' is crazy.  The HTML appears to have a table structure, but that table structure is overwritten by each repeating api. So every time AJAX repeats that api call it returns in json format the whole table definition as well as table cell contents, despite that much of that json (all that HTML defining table header, table rows, table cells, etc.; and the units for each value) does not change and it is only some values and times buried within the json in the api that actually might change (and of those half of them, the yesterday values and times only change once a day).  In some code I wrote (but later abandoned) I made use of the api calls that support the '''CumulusMX/interface/todayyest.html''' web page to get the units I wanted on another interface page, but I only called it once as it returned a lot of other information (as just mentioned) that I did not need. I later found a better way, as in example below, which gives me just what I need and no more.
 
== "GET" approach ==


You may have used GET as an attribute when defining the action of a HTML form.  Equally you might in a script language access the query-string part of a Universal Resource Locator to get parameters for what the script is to supply to the web page.  Even if you don't understand the meaning of those technical terms, you probably have seen when using a browser (in the box where a URL is entered) that sometimes the URL seen there has a query-string. You will have seen a question mark (?) followed by one or [separated by ampersand (&)] more '''name=value''' parameters.
Can be used with relevant format parameters to indicate correct day on yesterdayT.htm template page, and can be used to return latest day stored on [[dayfile.txt]] and NOAA report for latest month.


The GET approach to using the Cumulus general api works in this way indicating the start of a query-string with a question mark and using ampersands to separate names. The difference is that a tag name (or list of tag names) is used instead of a name=value parameter (or list of name=value parameters).  However, when the Cumulus api returns the values they will be in attribute=value format.  Therefore if (like example below) you are coding in JavaScript, what is returned is a JavaScript Object and you extract the values by specifying the Object name and the Attribute name. If that technical terminology confuses you, look at the example.
if you use PHP Hypertext preprocessor, you can output different text for before and after rollover, e.g.
<pre><?php
if('<#yesterday format=dddd>' == '<#metdateyesterday format=dddd>') echo '(calendar date and meteorological date same)';
else echo 'rollover still to happen, these results will be treated as belonging to <#metdate format=dddd>';?></pre>
|-
|<#yesterday>
|Yesterday's date.  The default format depends on the locale you use to run Cumulus
|-
|<#update>
|The date and time of the last web site update.  The default format depends on the locale you use to run Cumulus
|-
|<#timeJavaScript>
|{{Version badge 1}} Not available in Cumulus 1.


===Selecting values using GET===
[[File:Badge vMx.png]]Available from version 3.5.2


Suppose you want to get the values for the following three web tags:
The JavaScript '''Date''' object contains the number of miliseconds since 00:00:00.000 UTC on 1st January 1970, that date and time is known as the UNIX Epoch.  In JavaScript, you can use <tt>Math.floor(new Date().getTime()/1000.0)</tt> This getTime method returns the time in milliseconds.  The web tag returns an integer (currently with 13 digits) representing the number of milliseconds since the UNIX epoch when the web tag was processed. It can be used in a script where you wish to re-express other times output by Cumulus MX into UTC (Coordinated Universal Time).  Mac OS X uses 00:00:00.000 UTC on 1st January 2001 as the starting time and date for its millisecond count, so that is considerably lower.
# <#RCtemp>
# <#RChum>
# <#RCdew>
Then the URL with query-string to use is '''http: //localhost:8998/api/tags/process.json?rc&temp&hum&dew'''


Obviously, if you have started MX with a port parameter like this:
Note that UTC is calculated using 9192631770 times a particular transition time for Caesium 133 as a basis for 1 second. GMT (Greenwich Mean Time) is calculated on the basis that 1 second is 1/86400 of the time taken for a whole (day) rotation of the Earth. UT1 (or solar time) is calculated from various space measurements. Periodically, leap seconds are added to UTC to realign it with UT1, but these leap seconds are not added to the count of milliseconds represented by this web tag.
<pre>sudo mono CumulusMX.exe -port 9999</pre>
then you change the 8998 port shown in the URL for the api to use the port you have selected e.g. '''http: //localhost:9999/api/tags/process.json?rc&temp&hum&dew'''


Do be aware that some devices will use a 32 bit signed integer to represent this number, and that will stop working on 19 January 2038, the year 2038 problem for computing world.
|-
|<#timeUnix>
|{{Version badge 1}} Not available in Cumulus 1.


The first parameter is '''rc''' to indicate that the tags that follow are to use decimal points not decimal commas, which is how many script languages expect to see values.  
[[File:Badge vMx.png]]Available from version 3.7.0
Remember that in current version (and some earlier versions) of MX, the above three web tags are exactly same as:
# <#temp rc=y>
# <#hum rc=y>
# <#dew rc=y>


Since '''rc=y'''  can be applied to several web tags that don't appear in [[Webtags#No_Commas]] table, this shows how the api can access values without commas for all those web tags that report in real numbers and allow that output modifier.
Unix tracks the number of seconds since the UNIX epoch. So this web tag can be used when you do not want the millisecond accuracy of the previous web tag. Like previous web tag this relates to UTC, so see details for that tag to find out more. This is equivalent in PHP 5 and PHP 7 to '''time();''' (in PHP 8, a parameter is mandatory for time function, so the call changes).
|-
|<#LastDataReadT>
|The date/time data was last read from the station. Default format for this tag is like this example '''18:30 on 30 December 2009''', but output parameters for both date and time can modify this to include seconds in 1.9.x builds and most MX builds such as per this example '<#LastDataReadT format="yyyy-MM-dd HH:mm:ss">'.
|-
|<#DaysSince30Dec1899>
|Day count (gives whole and fractional part) Example: 41250.6523310301
|-
|<#recordsbegandate>
|Date when records began (appears twice on "recordT.htm" provided in standard web page, and used to calculate next tag, but ignored for all other Cumulus processing). Any output parameters valid for a date can be used here, don't forget differences in modifiers for Cumulus 1 and MX. There is no time associated with this web tag.  The default format is like 30 December 2009, please note although this web tag reports the value associated with  [b]StartDate=dd/MM/yyyy[/b] (see [[Cumulus.ini#Section:_Station]]), the format there is short-date format and different to default format for this web tag.  
|-
|<#DaysSinceRecordsBegan>
|Day count since Cumulus records started
|}


If you are using the api in a context where it does not matter if decimal commas or decimal points are in the api or for any tags that don't report in real numbers, simply omit the '''rc''' as first item, and just include tag names separated by ampersands.
==Current Conditions==


=== JavaScript example ===
The web tags/token shown here are mainly determined by which appear on "Now" page (index.htm).
Rainfall this month and this year are included here for consistency with supplied web templates (indexT.htm, thismonthT.htm, and thisyearT.htm) and with the dashboard 'Now' part of the Cumulus MX user; although you might expect to find them listed in tables for this month and this year, those web pages do not show these derivatives.
Those listed here cover both measurements obtained from a weather station (like air temperature, wind speed and direction, humidity and barometric pressure); and all the derived values (like humidex, feels like, apparent temperature, wind chill and heat index).


Some people might feel the admin interface could be improved on some of its pages by showing additional information. It is possible from MX 3.7.0 to obtain extra information. 
Note however, that the derived values calculated for Cumulus 1 and for MX may not agree, see derived value section within Recent History tags section for examples.
 
{| class="wikitable" border="1"
I wanted to improve the log file editing pages, and that was partly by adding validation, and partly by changing the way the editing is done.  For the standard log file editor I wanted to achieve even more, I added a script to calculate (and recalculate after any edit) the derived fields from the source fields.  To make these calculations work for anyone, I needed to find out what units the Cumulus MX user is using. Before 3.7.0 release the snippet of script that obtained the units via various api calls was quite complex (I described above how the api returned lots of unwanted content), but with 3.7.0 my new api call was greatly simplified to what I show below. Please note my revised log file editing scripts did not make it into a public release, and it is only the units obtaining api that I am making available to public here.
|-
 
!style="width:150px" | Web tag_name
Here is the code (with the api call written using jQuery):
!style="width:600px" | Function
<pre>/*    Some new variables connected with new api call (MX 3.7.0)  */
|-
var tempLetter;  // C or F
|colspan="2" style="background:lightgray;"|Temperature
var rainUnit; // mm or in
|-
var windUnit; // any units in style allowed by Cumulus
|<#temp>
/*  The one extra api request included to obtain the units used for temperature, rainfall, and wind speed */
|The outside (air) temperature
$.get('./api/tags/process.json?tempunitnodeg&rainunit&windunit', "limit=1", callUnits);
|-
function callUnits(unitsObject)
|<#intemp>
{
|The inside temperature
tempLetter = unitsObject.tempunitnodeg;
|-
rainUnit = unitsObject.rainunit;
|<#temptrend>
windUnit = unitsObject.windunit;
|The average rate of change in temperature over the last three hours. Trend = (temp_now - temp_3hrs_ago) / 3
console.log("new api", tempLetter, rainUnit,windUnit);
|-
}</pre>
|<#temptrendtext>
A little bit of explanation might help:
|Temperature change over the last three hours - Rising/Falling/Steady (values can be set in strings.ini)
*JavaScript variables generally need to be declared first, I have used 3 separate line each starting with '''var''', but you can list several variables on one line using a comma to separate them
|-
*In my script it is important to define these variables outside the function as I will explain later
|<#temptrendenglish>
*The jQuery get request takes the api URL as first parameter and the function to deal with the returned result as third parameter
|Temperature change over the last three hours - Rising/Falling/Steady (for use by [[Webtags_as_boolean_operators_in_HTML|HTML]], [[Editing_content_of_a_webpage_using_either_HTML_or_Script|javascript]] etc, values can't be changed)
*The middle parameter is irrelevant in this context as only one object instance is returned, but if the qet was returning multiple results, "limit=1" would only return the first result
|-
*The function takes as its sole parameter an Object (a JavaScript Object is a collection of properties), this is what is returned by the api, an object can be given any variable name
|<#TempChangeLastHour>
*In JavaScript if a variable is defined outside the function, then given a value inside the function, that value can be accessed by later code outside the function (in my case by code within the other functions for calculating each derived value)
|The change in temperature over the last hour
*We are only interested in 3 of the '''property_name = property_value''' items in the Object.
|-
*The JavaScript '''refinement''' syntax (starts with a dot) can be used to find the value for any parameter we name. We assign the variable already defined to the object and its refinement (that specifies the attribute we want).
|<#heatindex>
*The console.log command simply outputs all the items in the list within the brackets into the browser console that in many browsers is displayed by selecting '''F12''' on the keyboard. I included this instead of the lengthy rest of my code that uses the units to do the various calculations correctly.
|Current [[heat index]].  The referenced page in weather terminology section of this Wiki explains it.
 
|-
== "POST" approach ==
|<#humidex>
 
|Current [http://en.wikipedia.org/wiki/Humidex Humidex]
The word "Post" in a computer environment means that the Hypertext Transfer Protocol (HTTP) used by the internet is being asked to transfer information enclosed in the body of the request message. Put slightly less technically in this approach you produce a text file with the details of what tags you want and send it to the api server. I suppose it is a bit like sending an email, its header (subject, author, date sent) is easy to view, but you need to open it to see what text is in the body.
|-
|<#apptemp>
|The [[Apparent_temperature|apparent]] temperature. The referenced page in weather terminology section of this Wiki explains it. The formula used is that defined by BOM. Although at temperatures above 20°C (68°F) Feels like reports an "apparent temperature" it uses a different formula.  
|-
|<#wchill>
|The current [[wind chill]] temperature.  The referenced page in weather terminology section of this Wiki explains it. For temperatures below 10°C (50°F) Feels like reports the same value.
|-
|<#feelslike>
|{{Version badge 1}} Not available in Cumulus 1.


You may have used POST as an attribute when defining the action of a HTML form. In that context the form is sent as the contents of a message to whatever web page is going to process the contents of that form.  
[[File:Badge vMx.png]]Not available in all MX versions. Please see sub-section below this table regarding availability by MX versions if you are using a MX version earlier than 3.6.10.


The post approach has a few advantages over get:
The current [[Feels_Like|Feels Like]] temperature.  The referenced page in weather terminology section of this Wiki explains it.
*The parameters are not shown in any query-string, so are not obvious to the person looking over your shoulder, nor do they appear in a history list of sites that the browser has visited.
|-
*If you fill out a form online, the post approach will be used as the content needs to be kept secure.
|<#IsFreezing>
**The get approach may be seen when you are navigating through a web site, and a selection is being remembered.
|If outside temperature is at or below 0°C/32°F. 0=Above freezing, 1=Below freezing
*The POST approach can handle very long requests and return a lot of information.
|-
**In contrast, a URL with query-string is restricted in total length (the restriction is dependent on a number of other factors, but might be at something like 1000 characters in total), so GET comes with a restriction on how many parameters can be specified.
|<#chillhours>
 
|The number of [[Heat/cold_degree_days_and_Chill_hours#Chill_Hours_and.2For_Air_Frost|'chill hours']] so far this season (threshold temperature and start date are configurable).
See https://cumulus.hosiene.co.uk/viewtopic.php?p=145050#p145050 for post example
|-
 
|colspan="2" style="background:lightgray;"|Humidity
=The Web Tags for Cumulus =
 
These are available in both Cumulus 1 and MX unless indicated by a version 1 or MX badge.
 
Here follow tables indicating what web tags/tokens can be used, tables group the web tags available by the basic purpose of the tags listed.
 
== System ==
 
Special tags returning information about the Windows device hosting Cumulus 1.
 
[[File:Badge vMx.png]]''If you are running MX, then most tags do not work.''
 
{| class="wikitable" border="1"
|-
|-
!style="width:150px" |Web tag_name
|<#hum>
!style="width:600px" |Function
|The outside [http://en.wikipedia.org/wiki/Humidity humidity]
|-
|-
|<#OsVersion>
|<#inhum>
|OS version, e.g. "Windows 7 x64 build 7600"
|The inside humidity
|-
|-
|<#OsLanguage>
|<#dew>
|OS language, e.g. "English"
|The current dew point
|-
|-
|<#SystemUpTime>
|<#wetbulb>
|{{Version badge 1}}How long the system has been up, e.g. "8 hours 21 minutes" (not available on MX)
|Estimated [http://en.wikipedia.org/wiki/Wet_bulb wet bulb] temperature, can be seen if hover over 'Dewpoint' on Cumulus 1 main screen
|-
|-
|<#ProgramUpTime>
|colspan="2" style="background:lightgray;"|Rainfall
|How long Cumulus has been running, e.g. "7 hours 55 minutes"
|-
|-
|<#CpuName>
|<#rfall>
|{{Version badge 1}}CPU type, e.g. "Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz" (not available on MX)
|The total rainfall so far today
|-
|-
|<#CpuCount>
|<#rrate>
|Number of processors, e.g. "4"
|The current rainfall rate
|-
|-
|<#MemoryStatus>
|<#rhour>
|{{Version badge 1}}Free and total system RAM, e.g. "4619/8191 MB (free/total)" (not available on MX)
|The rainfall in the last hour
|-
|-
|<#DisplayMode>
|<#rmidnight>
|{{Version badge 1}}Screen display mode, e.g. "1680x1050, 32 bit" (not available on MX)
|The total rainfall since midnight. Useful if you don't use midnight as your start of day
|-
|-
|<#AllocatedMemory>
|<#r24hour>
|{{Version badge 1}}Amount of memory allocated to Cumulus, e.g. "18.76 MB" (not available on MX)
|Amount of rain in the last 24 hours
|-
|-
|<#DiskSize>
|<#LastRainTipISO>
|{{Version badge 1}}Size of disk on which Cumulus is running, e.g. "931.51 GB" (not available on MX)
|Fixed ISO format output giving date and time of last rain gauge tip (e.g 2010-09-06 06:09) The format is a shown, and cannot be modified by locale or addition of parameters.
|-
|-
|<#DiskFree>
|<#LastRainTip>
|{{Version badge 1}}Free space on disk on which Cumulus is running, e.g. "515.36 GB" (not available on MX)
| (available from release 3.6.1) Date/time of last rain gauge tip (default format is as set in locale) '''PLEASE NOTE: this web tag WILL accept any date and time output format modifiers'''
|}
 
== Miscellaneous ==
 
All tags are available in all flavours, as far as I know, although their output might vary, and which input/output parameters they permit might vary between Cumulus 1 and MX.
 
{| class="wikitable" border="1"
|-
|-
!style="width:150px" |Web tag_name
|<#MinutesSinceLastRainTip>
!style="width:900px" | Function
|The number of minutes since the last rain gauge tip, in whole numbers, rounded down
|-
|-
|<#LatestError>
|<#IsRaining>
|Displays the last error from the Cumulus 1 error log. (The value is cleared when you click the error light in Cumulus 1).<br />
|For [[Rain_measurement#Optical_Rain_Gauge| Hydreon RG-11 devices]], shows the current rain state. 0=No rain, 1=It's raining
Note: This tag displays ''all'' errors, even if they do not cause the error light to flash in Cumulus 1. Although this tag and the next 3 are in MX, none of them are actually used (as at April 2020).
|-
|-
|<#LatestErrorDate>
|<#rmonth>
|The date of the latest error logged to the error log window, using the system short date format. Gives dashes when latest error is reset
|The total rainfall so far this month
|-
|-
|<#LatestErrorTime>
|<#ryear>
|The time of the latest error logged to the error log window, using the system short time format. Gives dashes when latest error is reset
|Annual rainfall total for rainfall season year (i.e. starting month as set on Configuration menu, station screen, Annual rainfall frame)
|-
|-
|<#ErrorLight>
|<#ConsecutiveRainDays>
|1 if the 'error' light is flashing, 0 if not
|The number of days up to (but not including) today where it has rained every day. The threshold amount of rain required to determine a rain day is configurable via the RainDayThreshold setting in cumulus.ini, the units for the threshold are the same as your rain units, meteorologists exclude dew (and other times when single tip of recorder).
|-
|-
|<#version>
|<#ConsecutiveDryDays>
|The version of Cumulus in use e.g. '1.9.4' or '3.4.1'
|The number of days up to (but not including) today since it last rained. The threshold amount of rain required to determine a rain day is configurable via the RainDayThreshold setting in cumulus.ini the units for the threshold are the same as your rain units
|-
|-
|<#build>
|colspan="2" style="background:lightgray;"|Pressure
|The build of Cumulus in use e.g. '10992' for latest Cumulus 1 patch
 
(Cumulus MX is under development so new builds are released frequently)
|-
|-
|<#NewBuildAvailable>
|<#press>
|'''Only available from release 3.7.0''' onwards, it is checked on start-up and once a day thereafter at a random time
|The [http://en.wikipedia.org/wiki/Sea_level_pressure sea level pressure]
*Returns a boolean value
**0 - MX running the latest build available
**1 - MX is running an earlier build that the latest public release
|-
|-
|<#NewBuildNumber>
|<#presstrendval>
|'''Only available from release 3.7.0''' onwards, it is checked on start-up and once a day thereafter at a random time
|The average rate of pressure change over the last three hours.
 
Displays the latest public release build number - eg. b3089
|-
|-
|<#realtimeinterval>
|<#presstrend>
|The realtime update interval in seconds (integer)
|The pressure trend in words - values can be set in the 'strings.ini' file
|-
|-
|<#interval>
|<#presstrendenglish>
|The web site update interval in minutes (integer)
| a singe word description for the pressure trend - Rising/Falling/Steady (for use by [[Webtags_as_boolean_operators_in_HTML|HTML]], [[Editing_content_of_a_webpage_using_either_HTML_or_Script|javascript]] etc, values can't be changed)
|-
|-
|<#rollovertime>
|<#altimeterpressure>
|The time that the logs rollover to the next day: 'Midnight', '9 am' or '10 am'
|Altimeter pressure. Pressure corrected to sea level using the station's altitude only. Same as sea-level pressure for non-Davis stations.
 
This is the end of the meteorological day, so if during Daylight Saving Time it is "10 am", then on the day DST ends it will return to "9 am" ensuring every meteorological day is exactly 24 hours long. If the time is "Midnight" or during DST it is "9 am", then days will be 23 or 25 hours long just on day clocks change, 24 hours otherwise.
|-
|-
|<#update>
|colspan="2" style="background:lightgray;"|Wind
|The date and time of the last web site update
|-
|-
|<#LastDataReadT>
|<#wlatest>
|The date/time data was last read from the station
|Current wind speed reading from console.  Corresponds to 'latest' on the Cumulus main screen.
|-
|-
|<#stationtype>
|<#bearing>
|The weather station [https://cumuluswiki.org/a/Cumulus.ini#Section:_Station model] description (you choose what text appears for this on 'Display' settings screen within Configuration menu - the field is at the bottom left of that screen).
|Current wind bearing in degrees
|-
|-
|<#latitude>
|<#currentwdir>
|The station [http://en.wikipedia.org/wiki/Latitude latitude] (as you entered during setup).
|Current wind bearing as a compass point - e.g. ESE
Supports an optional 'dp' parameter, if supplied, instead of the usual web-encoded text format with degrees/minutes/seconds, the result is in decimal degrees to the specified number of decimal places. E.g<br />
<#latitude> gives "N&nbsp;59& deg;&amp;nbsp;14&amp;#39;&amp;nbsp;33&amp;quot;" for N 59 14 33<br />
<#latitude dp=5> gives "59.24250"
 
If the "dp" parameter is supplied, then supplying "rc=y" in addition will cause any decimal comma to be converted to a decimal point.
|-
|-
|<#longitude>
|<#wspeed>
|The station [http://en.wikipedia.org/wiki/Longitude longitude]  (as you entered during setup). Supports an optional 'dp' and 'rc' parameters as per the latitude tag.
|The 10-minute average, if you have Cumulus set to calculate a 10-minute average. Otherwise, it's the latest 'wind' value from the console (i.e. the current speed as determined by the station). Corresponds to 'average' on the Cumulus main screen.
|-
|-
|<#altitude>
|<#avgbearing>
|The station [http://en.wikipedia.org/wiki/Altitude altitude] value (webtag outputs web encoded format containing figure, '&amp;nbsp;' and units) in either feet or metres just as you entered during setup (so it is more complex to extract number for script arithmetric); e.g. '123&amp;nbsp;m'
|Average wind bearing in degrees over last 10 minutes. Range 1-360, 0=Calm
|-
|-
|<#location>
|<#wdir>
|The station location (as you entered during setup)
|Average wind bearing over last 10 minutes as a [http://en.wikipedia.org/wiki/Compass compass] point - e.g. ESE
|-
|-
|<#longlocation>
|<#wgust>
|Longer description of the station location (as you entered during setup)
|The highest wind reading in the last 10 minutes. Corresponds to 'gust' on the Cumulus main screen.
|-
|-
|<#forum>
|<#wdirdata>
|URL of the forum (as you entered during setup)
|Comma separated list of recent wind bearing readings (every x seconds, up to 3600 entries). This is a circular buffer; to find the most recent value use nextwindindex. Reading interval x varies by station type.
For Cumulus 1, this defaults to a Sandaysoft URL that is no longer available, for MX this defaults to the current support forum hosted by "Freddie" web server site
|-
|-
|<#webcam>
|<#wspddata>
|URL of the webcam (as you entered during setup). Default is blank. Can be used to link to any other web page that you host (Cumulus does not verify that it is a web can, that is just a label, and the label can be changed on each standard web page individually)
|Comma separated list of recent individual (non-averaged) wind speed (correspond to 'latest' on the Cumulus main screen) readings (every x seconds, up to 3600 entries). This is a circular buffer; to find the most recent value use nextwindindex. Reading interval x varies by station type.
|-
|-
|<#graphperiod>
|<#nextwindindex>
|The number of hours displayed by the graphs, as set using '''Configuration''' menu, ''Display'' settings screen 'Detailed Chart Period'  
|The index of the entries in wdirdata and wspddata which Cumulus is going to use next - i.e. the latest entry used is one less than this; but don't forget to allow for the wrap around!
|-
|-
|<#dailygraphperiod>
|<#beaufort>
|The number of days displayed by the graphs, as set using '''Configuration''' menu, ''Display'' settings screen 'Daily Chart Period' (available from build 1098)
|The current wind speed on the [http://en.wikipedia.org/wiki/Beaufort_scale Beaufort scale] (e.g. F8)  
|-
|-
|<#LatestNOAAMonthlyReport>
|<#beaufortnumber>
|Gives file name of latest auto-saved NOAA monthly report
|The current wind speed on the Beaufort scale, without a leading "F", e.g. "6"
|-
|-
|<#LatestNOAAYearlyReport>
|<#beaudesc>
|Gives file name of latest auto-saved NOAA yearly report
|The current wind speed Beaufort description (e.g. "Gale")
|}
 
==Units==
 
Apply to Cumulus 1 and MX, no optional input nor output parameters.
{| class="wikitable" border="1"
|-
|-
!style="width:150px" | Web tag_name
|<#BearingRangeFrom>
!style="width:600px" | Function
|The 'lowest' clockwise bearing in the last 10 minutes (or as configured using AvgBearingMinutes in cumulus.ini)
|-
|-
|<#tempunit>
|<#BearingRangeTo>
|Unit of temperature being used (Set in Cumulus as [http://en.wikipedia.org/wiki/Centigrade Celsius] or [http://en.wikipedia.org/wiki/Fahrenheit Fahrenheit]) values "&amp;deg;C" or "&amp;deg;F"
|The 'highest' clockwise bearing in the last 10 minutes (or as configured using AvgBearingMinutes in cumulus.ini)
|-
|-
|<#tempunitnodeg>
|<#BearingRangeFrom10>
|The temperature units being used, without a degree symbol, i.e. "F" or "C"
|The 'lowest' clockwise bearing in the last 10 minutes (or as configured using AvgBearingMinutes in cumulus.ini), rounded down to nearest 10 degrees
|-
|-
|<#pressunit>
|<#BearingRangeTo10>
|Unit of measure for pressure. Possible values: "mb", "hPa", "in"
|The 'highest' clockwise bearing in the last 10 minutes (or as configured using AvgBearingMinutes in cumulus.ini), rounded down to nearest 10 degrees
|-
|-
|<#rainunit>
|<#WindRoseData>
|Unit of measure for rain fall. Possible values: "mm" or "inches"
|A comma-separated list of the wind 'totals' used to draw the wind rose (8 or 16 values)
|-
|-
|<#windunit>
|<#WindRosePoints>
|Unit of measure for wind speed. Possible values: "m/s", "mph", "km/h", "kts"
|The number of items in <#WindRoseData> (i.e. 8 or 16)
|-
|-
|<#windrununit>
|<#WindSampleCount>
|Unit of measure for wind run (distance). Possible values: "km", "miles", "km", "nm" (for wind speeds in m/s, mph, km/h, kts)
|The number of wind samples making up the wind rose (etc) data (up to 3600)
|-
|-
|<#cloudbaseunit>
|colspan="2" style="background:lightgray;"|Miscellaneous
|The units used for cloudbase value. Possible values:  "ft" or "m"
|}
 
==Date & Time==
Both Cumulus 1 and MX support all of these, except where marked as MX only, most of these web tags can be used with output parameters.
{| class="wikitable" border="1"
|-
|-
!style="width:150px" |Web tag_name
|<#cloudbase>
!style="width:600px" | Function
|Calculated [http://en.wikipedia.org/wiki/Cloud_base cloud base]
|-
|-
|<#date>
|<#cloudbasevalue>
|The current date - format depends on locale you use to run Cumulus
|Current calculated cloud base without units
|-
|-
|<#metdate>
|<#UV>
|The current meteorological date. The default format depends on the locale you use to run Cumulus
|Current [http://en.wikipedia.org/wiki/Uv_index UV index]. Requires your station to have a UV sensor.
*If you use midnight rollover, this returns same date as <#date> (above), but with a different default format.
*If using a 9am/10am rollover:
**After rollover time on current calendar date,  this is same as <#date>, but with a different default format.
**Between midnight and 9am/10am the <#metdate> will return the date associated with previous calendar day, but will still return current time 
 
{{Version badge 1}}Can be used with relevant format parameters to [[Customised templates|customise]] '''todayT.htm''' template page to display current meteorological day, to customise '''thismonthT.htm''' template page to display meteorological month, and to customise '''thisyearT.htm''' template page to display correct meteorological year. This will be particularly useful on first and last day of month/year when rollover happens at 9 (or 10) a.m. and the month (and maybe year) is different before and after rollover.
 
[[File:Badge vMx.png]] Earlier MX releases provide a similar web template set, so these can be customised in same way as for legacy Cumulus above (but note capital "M" must be used for any month formatting). From release 3.10.1 the supplied web pages are web server based, there are no web templates to customise, and the supplied '''.json files''' do not include any meteorological date functionality.
|-
|-
|<#timeUTC>
|<#SolarRad>
|The current UTC date/time rather than local date/time. Example result (actual format depends on locale settings): 18:30 on 30 December 2009. If you want the local date and time, use next tag (below).
|Current [http://en.wikipedia.org/wiki/Solar_radiation solar radiation]. Requires your station to have a solar sensor.
|-
|-
|<#time>
|The current time and date. Example result (actual format depends on locale settings): 18:30 on 30 December 2009.  If you simply wish the time, use next tag (below).
|-
|-
|<#timehhmmss>
|<#Light>
|The current time (without date). Example format: 18:30:27. You can use output format specifiers to change the way the time is output, but any date specifiers are ignored.
|Current Current light level in Lux. Requires your station to have a solar sensor. Only applies to Fine Offset stations.
|-
|-
|<#minute>
|[[Forecast_webtag|<#forecast>]]
|The current time, just the minutes. Example format: 07
|The current forecast
|-
|-
|<#hour>
|<#forecastenc>
|The current time, just the hour. Example format: 07
|The same as <#forecast> but with all reserved HTML characters, and those above character code 159, encoded as HTML entities
|-
|-
|<#day>
|<#forecastnumber>
| The current day as a 2-digit number. Example format: 07 
|The number relating to the current forecast entry in the [[strings.ini]] file.  If your station is not providing it's own forecast and Cumulus is not calculating one then 0 (zero) is returned. Note: two negative numbers can be returned by [[Forecast_webtag|Cumulus]]: -1 (neg 1) = Exceptional Fine, -26 (neg 26) = Exceptional Bad
|-
|-
|<#dayname>
|<#cumulusforecast>
| The current day as a word.  For example, Monday  (actual format depends on locale settings)
|Always gives Cumulus (Zambretti) [[Forecast_webtag|forecast]], even if the <#forecast> tag provides a station forecast
|-
|-
|<#shortdayname>
|<#cumulusforecastenc>
| The current day as a shortened word. Example format: Mon
|The same as <#cumulusforecast> but with all reserved HTML characters, and those above character code 159, encoded as HTML entities
|-
|-
|<#month>
|<#wsforecast>
|The current month as a 2-digit number. Example format: 07
|Always gives station forecast (if available)
|-
|<#monthname>
|The current month as a word. Example format: July
|-
|-
|<#shortmonthname>
|<#wsforecastenc>
|The current month as a shortened word. Example format: Jul
|The same as <#wsforecast> but with all reserved HTML characters, and those above character code 159, encoded as HTML entities
|-
|-
|<#year>
|<#currcond>
|The current year as a 4-digit number. Example format: 2009
|Represents the value entered on the screen within Cumulus for the Current Weather condition, or the value as held in the [[currentconditions.txt]] file. Any reserved HTML characters are encoded as HTML entities
|-
|-
|<#shortyear>
|<#currcondenc>
|The current year as a 2-digit number. Example format: 09
|The same as <#currcond> but also has all characters above (decimal base) code 159 encoded as HTML entities for example this would encode any use of symbol for degree.
|-
|}
|<#rollovertime>
==== Feels Like ====
|The time that the logs rollover to the next day: 'Midnight', '9 am' or '10 am'


PHP code example for testing whether before or after rollover given in next entry.
Feels like temperature was first made available, just for current conditions at MX version 3.5.4.  In version 3.6.0. it was extended to add max/min for each day, each month, each year, and all time. In version 3.6.11 it was added to recent history.
|-
|<#metdateyesterday>
|The previous meteorological date.  The default format depends on the locale you use to run Cumulus
*If you use midnight rollover, this returns same date as <#date>, but with a different default format.
*If using a 9am/10am rollover:
**After rollover time on current calendar date, this is same as <#yesterday> (below), but with a different default format.
**Between midnight and 9am/10am the date output by <#metdateyesterday> will be the calendar day before that returned by <#yesterday>, but the time returned is actual local time.


Can be used with relevant format parameters to indicate correct day on yesterdayT.htm template page, and can be used to return latest day stored on [[dayfile.txt]] and NOAA report for latest month.


if you use PHP Hypertext preprocessor, you can output different text for before and after rollover, e.g.
The figures quoted for this derivative vary between versions:
<pre><?php
* The first formula was used from MX version 3.5.4 (25 Apr 2020) build 3075 until version 3.6.7 (4 June 2020) build 3083
if('<#yesterday format=dddd>' == '<#metdateyesterday format=dddd>') echo '(calendar date and meteorological date same)';
* The second formula, which was coded incorrectly, and so gave strange results, applied in versions 3.6.8 to 3.6.9 (build 3084, 3085)
else echo 'rollover still to happen, these results will be treated as belonging to <#metdate format=dddd>';?></pre>
* The third, and hopefully final, formula applies from version 3.6.10 (build 3086).
|-
|<#yesterday>
|Yesterday's date.   The default format depends on the locale you use to run Cumulus
|-
|<#update>
|The date and time of the last web site update.   The default format depends on the locale you use to run Cumulus
|-
|<#timeJavaScript>
|{{Version badge 1}} Not available in Cumulus 1.


[[File:Badge vMx.png]]Available from version 3.5.2
A php script for adding feels like as calculated in version 3.6.10 to any standard log line created either without feels like, or with an older (now incorrect) calculation, can be downloaded from [https://cumulus.hosiene.co.uk/viewtopic.php?f=18&t=18096 Create Missing topic on support forum]. Obviously, this calculates from the small sub-set of current conditions that have been logged, and is not as accurate at deriving maximum and minimum as derivation made as each reading is processed by MX (so including all current conditions).


The JavaScript '''Date''' object contains the number of miliseconds since 00:00:00.000 UTC on 1st January 1970, that date and time is known as the UNIX Epoch.  In JavaScript, you can use <tt>Math.floor(new Date().getTime()/1000.0)</tt> This getTime method returns the time in milliseconds.  The web tag returns an integer (currently with 13 digits) representing the number of milliseconds since the UNIX epoch when the web tag was processed. It can be used in a script where you wish to re-express other times output by Cumulus MX into UTC (Coordinated Universal Time).  Mac OS X uses 00:00:00.000 UTC on 1st January 2001 as the starting time and date for its millisecond count, so that is considerably lower.
==Extra Sensors Davis (and a few others)==


Note that UTC is calculated using 9192631770 times a particular transition time for Caesium 133 as a basis for 1 second. GMT (Greenwich Mean Time) is calculated on the basis that 1 second is 1/86400 of the time taken for a whole (day) rotation of the Earth. UT1 (or solar time) is calculated from various space measurements. Periodically, leap seconds are added to UTC to realign it with UT1, but these leap seconds are not added to the count of milliseconds represented by this web tag.
These web tags hold current values for additional sensors supported by Cumulus. Most of the tags in this section relate to Davis stations, but not exclusively.


Do be aware that some devices will use a 32 bit signed integer to represent this number, and that will stop working on 19 January 2038, the year 2038 problem for computing world.
Some tags are only available for certain builds, see general tip at top of page to check for the build you are using. In particular Cumulus 1 has fewer channels available.
|-
|<#timeUnix>
|{{Version badge 1}} Not available in Cumulus 1.


[[File:Badge vMx.png]]Available from version 3.7.0
There are no web tags for past values from extra sensors, see the [[Extra_Sensor_Files]] page for information about log files from where you can extract those values.


Unix tracks the number of seconds since the UNIX epoch. So this web tag can be used when you do not want the millisecond accuracy of the previous web tag. Like previous web tag this relates to UTC, so see details for that tag to find out more. This is equivalent in PHP 5 and PHP 7 to '''time();''' (in PHP 8, a parameter is mandatory for time function, so the call changes).
{| class="wikitable" border="1"
|-
|-
|<#LastDataReadT>
!style="width:150px"|Web tag_name
|The date/time data was last read from the station. Default format for this tag is like this example '''18:30 on 30 December 2009''', but output parameters for both date and time can modify this to include seconds in 1.9.x builds and most MX builds such as per this example  '<#LastDataReadT format="yyyy-MM-dd HH:mm:ss">'.
!style="width:600px"|The related description can be changed in 'strings.ini', but below are default descriptions that will be shown in viewer/editor
|-
|-
|<#DaysSince30Dec1899>  
|<#ExtraTemp1>
|Day count (gives whole and fractional part) Example: 41250.6523310301
|Extra temperature channel 1
|-
|-
|<#recordsbegandate>
|<#ExtraTemp2>
|Date when records began (appears twice on "recordT.htm" provided in standard web page, and used to calculate next tag, but ignored for all other Cumulus processing). Any output parameters valid for a date can be used here, don't forget differences in modifiers for Cumulus 1 and MX. There is no time associated with this web tag.  The default format is like 30 December 2009, please note although this web tag reports the value associated with  [b]StartDate=dd/MM/yyyy[/b] (see [[Cumulus.ini#Section:_Station]]), the format there is short-date format and different to default format for this web tag.
|Extra temperature channel 2
|-
|-
|<#DaysSinceRecordsBegan>
|<#ExtraTemp3>
|Day count since Cumulus records started
|Extra temperature channel 3
|}
 
==Current Conditions==
 
The web tags/token shown here are mainly determined by which appear on "Now" page (index.htm).
Rainfall this month and this year are included here for consistency with supplied web templates (indexT.htm, thismonthT.htm, and thisyearT.htm) and with the dashboard 'Now' part of the Cumulus MX user; although you might expect to find them listed in tables for this month and this year, those web pages do not show these derivatives.
Those listed here cover both measurements obtained from a weather station (like air temperature, wind speed and direction, humidity and barometric pressure); and all the derived values (like humidex, feels like, apparent temperature, wind chill and heat index).
 
Note however, that the derived values calculated for Cumulus 1 and for MX may not agree, see derived value section within Recent History tags section for examples.
{| class="wikitable" border="1"
|-
|-
!style="width:150px" | Web tag_name
|colspan="2"|... and so on up to <#ExtraTemp10> = Extra temperature channel 10
!style="width:600px" | Function
|-
|-
|colspan="2" style="background:lightgray;"|Temperature
|<#ExtraDP1>
|Extra dew point channel 1
|-
|-
|<#temp>
|<#ExtraDP2>
|The outside (air) temperature
|Extra dew point channel 2
|-
|-
|<#intemp>
|<#ExtraDP3>
|The inside temperature
|Extra dew point channel 3
|-
|-
|<#temptrend>
|colspan="2"|... and so on up to <#ExtraDP10>
|The average rate of change in temperature over the last three hours. Trend = (temp_now - temp_3hrs_ago) / 3
|-
|-
|<#temptrendtext>
|<#ExtraHum1>
|Temperature change over the last three hours - Rising/Falling/Steady (values can be set in strings.ini)
|Extra humidity channel 1
|-
|-
|<#temptrendenglish>
|<#ExtraHum2>
|Temperature change over the last three hours - Rising/Falling/Steady (for use by [[Webtags_as_boolean_operators_in_HTML|HTML]], [[Editing_content_of_a_webpage_using_either_HTML_or_Script|javascript]] etc, values can't be changed)
|Extra humidity channel 2
|-
|-
|<#TempChangeLastHour>
|<#ExtraHum3>
|The change in temperature over the last hour
|Extra humidity channel 3
|-
|-
|<#heatindex>
|colspan="2"|... and so on up to <#ExtraHum10>
|Current [[heat index]].  The referenced page in weather terminology section of this Wiki explains it.
|-
|-
|<#humidex>
|<#SoilTemp1>
|Current [http://en.wikipedia.org/wiki/Humidex Humidex]
|Soil temperature 1
|-
|-
|<#apptemp>
|<#SoilTemp2>
|The [[Apparent_temperature|apparent]] temperature.  The referenced page in weather terminology section of this Wiki explains it. The formula used is that defined by BOM. Although at temperatures above 20°C (68°F) Feels like reports an "apparent temperature" it uses a different formula.
|Soil temperature 2
|-
|-
|<#wchill>
|colspan="2"|... and so on up to <#SoilTemp16>
|The current [[wind chill]] temperature. The referenced page in weather terminology section of this Wiki explains it. For temperatures below 10°C (50°F) Feels like reports the same value.
|-
|-
|<#feelslike>
|<#SoilMoisture1>
|{{Version badge 1}} Not available in Cumulus 1.
|Soil moisture 1
 
[[File:Badge vMx.png]]Not available in all MX versions. Please see sub-section below this table regarding availability by MX versions if you are using a MX version earlier than 3.6.10.
 
The current [[Feels_Like|Feels Like]] temperature.  The referenced page in weather terminology section of this Wiki explains it.
|-
|-
|<#IsFreezing>
|<#SoilMoisture2>
|If outside temperature is at or below 0°C/32°F. 0=Above freezing, 1=Below freezing
|Soil moisture 2
|-
|-
|<#chillhours>
|colspan="2"|... and so on up to <#SoilMoisture16>
|The number of [[Heat/cold_degree_days_and_Chill_hours#Chill_Hours_and.2For_Air_Frost|'chill hours']] so far this season (threshold temperature and start date are configurable).
|-
|-
|colspan="2" style="background:lightgray;"|Humidity
|<#LeafTemp1>
|Leaf temperature 1
|-
|-
|<#hum>
|<#LeafTemp2>
|The outside [http://en.wikipedia.org/wiki/Humidity humidity]
|Leaf temperature 2
|-
|-
|<#inhum>
|<#LeafWetness1>
|The inside humidity
|Leaf wetness 1
|-
|-
|<#dew>
|<#LeafWetness2>
|The current dew point
|Leaf wetness 2
|}
 
==Extra Sensors Ecowitt==
 
{{Version badge 1}} Not available in Cumulus 1.
 
[[File:Badge vMx.png]] Please see release announcements for when individual web tags become available.
 
This section applies only to those using Ecowitt GW1000 (Froggit DS1500) an interface unit that picks up various external sensors and sends the data via an application programming interface to MX which then generates the following web tags:
 
{| class="wikitable" border="1"
|-
|-
|<#wetbulb>
!style="width:150px" |Web tag_name
|Estimated [http://en.wikipedia.org/wiki/Wet_bulb wet bulb] temperature, can be seen if hover over 'Dewpoint' on Cumulus 1 main screen
!style="width:600px" |Function
|-
|-
|colspan="2" style="background:lightgray;"|Rainfall
|<#GW1000FirmwareVersion>
|{{Version badge 1}} Not available in Cumulus 1.
 
[[File:Badge vMx.png]]GW1000 firmware version string
|}
 
 
{| class="wikitable" border="1"
|-
|-
|<#rfall>
!style="width:150px"|Web tag_name
|The total rainfall so far today
!style="width:600px"|The related description can be changed in 'strings.ini', but below are default descriptions that will be shown in the viewer/editor
|-
|-
|<#rrate>
|<#AirQuality1>
|The current rainfall rate
|{{Version badge 1}} Not available in Cumulus 1.
 
[[File:Badge vMx.png]] see release announcements for version availability
 
Air quality 1
|-
|-
|<#rhour>
|colspan="2"|... and so on up to <#AirQuality4>
|The rainfall in the last hour
|-
|-
|<#rmidnight>
|<#LeakSensor1>
|The total rainfall since midnight. Useful if you don't use midnight as your start of day
 
|{{Version badge 1}} Not available in Cumulus 1.
 
[[File:Badge vMx.png]] see release announcements for version availability
 
Leak sensor - 0 or 1
|-
|-
|<#r24hour>
|colspan="2"|... and so on up to <#LeakSensor4>
|Amount of rain in the last 24 hours
|-
|-
|<#LastRainTipISO>
|<#LightningDistance>
|Fixed ISO format output giving date and time of last rain gauge tip (e.g 2010-09-06 06:09) The format is a shown, and cannot be modified by locale or addition of parameters.
 
|{{Version badge 1}} Not available in Cumulus 1.
 
[[File:Badge vMx.png]] see release announcements for version availability
 
Distance to last strike (same units as wind run - miles/km/nm) (Returns 0.0 if you don't have a sensor, GW1000 api returns max value you can put in a byte - 0xFF which translates to 158.4 miles = 255 km if have sensor but no strike detected yet, so MX translates that to '----')
|-
|-
|<#LastRainTip>
|<#LightningTime>
| (available from release 3.6.1) Date/time of last rain gauge tip (default format is as set in locale) '''PLEASE NOTE: this web tag WILL accept any date and time output format modifiers'''
 
|{{Version badge 1}} Not available in Cumulus 1.
 
[[File:Badge vMx.png]] see release announcements for version availability
 
Date and Time of last strike (default without output parameters is locale's short time format e.g. 18:02 or 6:02 pm, without date, but tag accepts both date and time output parameters). Returns '----' if you don't have sensor or there has not been a strike since the sensor was installed. (GW1000 api returns FFFF FFFF seconds after midnight on 01 Jan 1970, which translates to 07/02/2106 06:28:15, so MX translates that to '----')
|-
|-
|<#MinutesSinceLastRainTip>
|<#LightningStrikesToday>
|The number of minutes since the last rain gauge tip, in whole numbers, rounded down
 
|{{Version badge 1}} Not available in Cumulus 1.
 
[[File:Badge vMx.png]] see release announcements for version availability
 
Number of strikes since midnight, default 0
|-
|-
|<#IsRaining>
|<#UserTemp1>  
|For [[Rain_measurement#Optical_Rain_Gauge| Hydreon RG-11 devices]], shows the current rain state. 0=No rain, 1=It's raining
 
|-
|{{Version badge 1}} Not available in Cumulus 1.
|<#rmonth>
|The total rainfall so far this month
|-
|<#ryear>
|Annual rainfall total for rainfall season year (i.e. starting month as set on Configuration menu, station screen,  Annual rainfall frame)
|-
|<#ConsecutiveRainDays>
|The number of days up to (but not including) today where it has rained every day. The threshold amount of rain required to determine a rain day is configurable via the RainDayThreshold setting in cumulus.ini, the units for the threshold are the same as your rain units, meteorologists exclude dew (and other times when single tip of recorder).
|-
|<#ConsecutiveDryDays>
|The number of days up to (but not including) today since it last rained. The threshold amount of rain required to determine a rain day is configurable via the RainDayThreshold setting in cumulus.ini the units for the threshold are the same as your rain units
|-
|colspan="2" style="background:lightgray;"|Pressure
|-
|<#press>
|The [http://en.wikipedia.org/wiki/Sea_level_pressure sea level pressure]
|-
|<#presstrendval>
|The average rate of pressure change over the last three hours.
|-
|<#presstrend>
|The pressure trend in words - values can be set in the 'strings.ini' file
|-
|<#presstrendenglish>
| a singe word description for the pressure trend - Rising/Falling/Steady (for use by [[Webtags_as_boolean_operators_in_HTML|HTML]], [[Editing_content_of_a_webpage_using_either_HTML_or_Script|javascript]] etc, values can't be changed)
|-
|<#altimeterpressure>
|Altimeter pressure. Pressure corrected to sea level using the station's altitude only. Same as sea-level pressure for non-Davis stations.
|-
|colspan="2" style="background:lightgray;"|Wind
|-
|<#wlatest>
|Current wind speed reading from console.  Corresponds to 'latest' on the Cumulus main screen.
|-
|<#bearing>
|Current wind bearing in degrees
|-
|<#currentwdir>
|Current wind bearing as a compass point - e.g. ESE
|-
|<#wspeed>
|The 10-minute average, if you have Cumulus set to calculate a 10-minute average. Otherwise, it's the latest 'wind' value from the console (i.e. the current speed as determined by the station). Corresponds to 'average' on the Cumulus main screen.
|-
|<#avgbearing>
|Average wind bearing in degrees over last 10 minutes. Range 1-360, 0=Calm
|-
|<#wdir>
|Average wind bearing over last 10 minutes as a [http://en.wikipedia.org/wiki/Compass compass] point - e.g. ESE
|-
|<#wgust>
|The highest wind reading in the last 10 minutes. Corresponds to 'gust' on the Cumulus main screen.
|-
|<#wdirdata>
|Comma separated list of recent wind bearing readings (every x seconds, up to 3600 entries). This is a circular buffer; to find the most recent value use nextwindindex. Reading interval x varies by station type.
|-
|<#wspddata>
|Comma separated list of recent individual (non-averaged) wind speed (correspond to 'latest' on the Cumulus main screen) readings (every x seconds, up to 3600 entries). This is a circular buffer; to find the most recent value use nextwindindex. Reading interval x varies by station type.
|-
|<#nextwindindex>
|The index of the entries in wdirdata and wspddata which Cumulus is going to use next - i.e. the latest entry used is one less than this; but don't forget to allow for the wrap around!
|-
|<#beaufort>
|The current wind speed on the [http://en.wikipedia.org/wiki/Beaufort_scale Beaufort scale] (e.g. F8)
|-
|<#beaufortnumber>
|The current wind speed on the Beaufort scale, without a leading "F", e.g. "6"
|-
|<#beaudesc>
|The current wind speed Beaufort description (e.g. "Gale")
|-
|<#BearingRangeFrom>
|The 'lowest' clockwise bearing in the last 10 minutes (or as configured using AvgBearingMinutes in cumulus.ini)
|-
|<#BearingRangeTo>
|The 'highest' clockwise bearing in the last 10 minutes (or as configured using AvgBearingMinutes in cumulus.ini)
|-
|<#BearingRangeFrom10>
|The 'lowest' clockwise bearing in the last 10 minutes (or as configured using AvgBearingMinutes in cumulus.ini), rounded down to nearest 10 degrees
|-
|<#BearingRangeTo10>
|The 'highest' clockwise bearing in the last 10 minutes (or as configured using AvgBearingMinutes in cumulus.ini), rounded down to nearest 10 degrees
|-
|<#WindRoseData>
|A comma-separated list of the wind 'totals' used to draw the wind rose (8 or 16 values)
|-
|<#WindRosePoints>
|The number of items in <#WindRoseData> (i.e. 8 or 16)
|-
|<#WindSampleCount>
|The number of wind samples making up the wind rose (etc) data (up to 3600)
|-
|colspan="2" style="background:lightgray;"|Miscellaneous
|-
|<#cloudbase>
|Calculated [http://en.wikipedia.org/wiki/Cloud_base cloud base]
|-
|<#cloudbasevalue>
|Current calculated cloud base without units
|-
|<#UV>
|Current [http://en.wikipedia.org/wiki/Uv_index UV index]. Requires your station to have a UV sensor.
|-
|<#SolarRad>
|Current [http://en.wikipedia.org/wiki/Solar_radiation solar radiation]. Requires your station to have a solar sensor.
|-
|-
|<#Light>
|Current Current light level in Lux. Requires your station to have a solar sensor. Only applies to Fine Offset stations.
|-
|[[Forecast_webtag|<#forecast>]]
|The current forecast
|-
|<#forecastenc>
|The same as <#forecast> but with all reserved HTML characters, and those above character code 159, encoded as HTML entities
|-
|<#forecastnumber>
|The number relating to the current forecast entry in the [[strings.ini]] file.  If your station is not providing it's own forecast and Cumulus is not calculating one then 0 (zero) is returned.  Note: two negative numbers can be returned by [[Forecast_webtag|Cumulus]]: -1 (neg 1) = Exceptional Fine, -26 (neg 26) = Exceptional Bad
|-
|<#cumulusforecast>
|Always gives Cumulus (Zambretti) [[Forecast_webtag|forecast]], even if the <#forecast> tag provides a station forecast
|-
|<#cumulusforecastenc>
|The same as <#cumulusforecast> but with all reserved HTML characters, and those above character code 159, encoded as HTML entities
|-
|<#wsforecast>
|Always gives station forecast (if available)
|-
|<#wsforecastenc>
|The same as <#wsforecast> but with all reserved HTML characters, and those above character code 159, encoded as HTML entities
|-
|<#currcond>
|Represents the value entered on the screen within Cumulus for the Current Weather condition, or the value as held in the [[currentconditions.txt]] file. Any reserved HTML characters are encoded as HTML entities
|-
|<#currcondenc>
|The same as <#currcond> but also has all characters above (decimal base) code 159 encoded as HTML entities for example this would encode any use of symbol for degree.
|}
==== Feels Like ====
 
Feels like temperature was first made available, just for current conditions at MX version 3.5.4.  In version 3.6.0. it was extended to add max/min for each day, each month, each year, and all time. In version 3.6.11 it was added to recent history.
 
 
The figures quoted for this derivative vary between versions:
* The first formula was used from MX version 3.5.4 (25 Apr 2020) build 3075 until version 3.6.7 (4 June 2020) build 3083
* The second formula, which was coded incorrectly, and so gave strange results, applied in versions 3.6.8 to 3.6.9 (build 3084, 3085)
* The third, and hopefully final, formula applies from version 3.6.10 (build 3086).
 
A php script for adding feels like as calculated in version 3.6.10 to any standard log line created either without feels like, or with an older (now incorrect) calculation, can be downloaded from [https://cumulus.hosiene.co.uk/viewtopic.php?f=18&t=18096 Create Missing topic on support forum]. Obviously, this calculates from the small sub-set of current conditions that have been logged, and is not as accurate at deriving maximum and minimum as derivation made as each reading is processed by MX (so including all current conditions).
 
==Extra Sensors Davis (and a few others)==
 
These web tags hold current values for additional sensors supported by Cumulus. Most of the tags in this section relate to Davis stations, but not exclusively.
 
Some tags are only available for certain builds, see general tip at top of page to check for the build you are using. In particular Cumulus 1 has fewer channels available.
 
There are no web tags for past values from extra sensors, see the [[Extra_Sensor_Files]] page for information about log files from where you can extract those values.
 
{| class="wikitable" border="1"
|-
!style="width:150px"|Web tag_name
!style="width:600px"|The related description can be changed in 'strings.ini', but below are default descriptions that will be shown in viewer/editor
|-
|<#ExtraTemp1>
|Extra temperature channel 1
|-
|<#ExtraTemp2>
|Extra temperature channel 2
|-
|<#ExtraTemp3>
|Extra temperature channel 3
|-
|colspan="2"|... and so on up to <#ExtraTemp10> = Extra temperature channel 10
|-
|<#ExtraDP1>
|Extra dew point channel 1
|-
|<#ExtraDP2>
|Extra dew point channel 2
|-
|<#ExtraDP3>
|Extra dew point channel 3
|-
|colspan="2"|... and so on up to <#ExtraDP10>
|-
|<#ExtraHum1>
|Extra humidity channel 1
|-
|<#ExtraHum2>
|Extra humidity channel 2
|-
|<#ExtraHum3>
|Extra humidity channel 3
|-
|colspan="2"|... and so on up to <#ExtraHum10>
|-
|<#SoilTemp1>
|Soil temperature 1
|-
|<#SoilTemp2>
|Soil temperature 2
|-
|colspan="2"|... and so on up to <#SoilTemp16>
|-
|<#SoilMoisture1>
|Soil moisture 1
|-
|<#SoilMoisture2>
|Soil moisture 2
|-
|colspan="2"|... and so on up to <#SoilMoisture16>
|-
|<#LeafTemp1>
|Leaf temperature 1
|-
|<#LeafTemp2>
|Leaf temperature 2
|-
|<#LeafWetness1>
|Leaf wetness 1
|-
|<#LeafWetness2>
|Leaf wetness 2
|}
 
==Extra Sensors Ecowitt==
 
{{Version badge 1}} Not available in Cumulus 1.


[[File:Badge vMx.png]] Please see release announcements for when individual web tags become available.
[[File:Badge vMx.png]] see release announcements for version availability


This section applies only to those using Ecowitt GW1000 (Froggit DS1500) an interface unit that picks up various external sensors and sends the data via an application programming interface to MX which then generates the following web tags:
User Temperature 1
 
support for the Ecowitt WH34 (other model types exist and are reported here as if WH34) soil and water temperature sensors
{| class="wikitable" border="1"
|-
|-
!style="width:150px" |Web tag_name
|colspan="2"|... and so on up to <#UserTemp8> = User temperature 8
!style="width:600px" |Function
|-
|<#GW1000FirmwareVersion>
|{{Version badge 1}} Not available in Cumulus 1.
 
[[File:Badge vMx.png]]GW1000 firmware version string
|}
|}




{| class="wikitable" border="1"
Ecowitt stations are sold under other names depending on nation,  e.g. Ambient in USA, Froggit in central Europe, so Ecowitt is used as a generic name in same way as Fine Offset is used elsewhere in this article.
|-
!style="width:150px"|Web tag_name
!style="width:600px"|The related description can be changed in 'strings.ini', but below are default descriptions that will be shown in the viewer/editor
|-
|<#AirQuality1>
|{{Version badge 1}} Not available in Cumulus 1.
 
[[File:Badge vMx.png]] see release announcements for version availability
 
Air quality 1
|-
|colspan="2"|... and so on up to <#AirQuality4>
|-
|<#LeakSensor1>
 
|{{Version badge 1}} Not available in Cumulus 1.
 
[[File:Badge vMx.png]] see release announcements for version availability


Leak sensor - 0 or 1
==Recent History==
|-
|colspan="2"|... and so on up to <#LeakSensor4>
|-
|<#LightningDistance>
 
|{{Version badge 1}} Not available in Cumulus 1.
 
[[File:Badge vMx.png]] see release announcements for version availability


Distance to last strike (same units as wind run - miles/km/nm) (Returns 0.0 if you don't have a sensor, GW1000 api returns max value you can put in a byte - 0xFF which translates to 158.4 miles = 255 km if have sensor but no strike detected yet, so MX translates that to '----')
There are a set of web tags for 'recent historical data', based on an array stored by Cumulus giving data values from 1 minute ago, up to 1 week ago, in 1 minute intervals. As Cumulus runs it will add the latest values to the array with full resolution, and shift existing values along so those older than 7 days fall off. 
|-
*The input modification parameters available are listed at [[Webtags/Parameters#Input Modification Parameters for Recent History]].
|<#LightningTime>
**To save you looking up the details, these input parameters specify how many minutes ago is required. Instead of entering a very large number for minutes, you can include separate input parameters for days, hours, and minutes, ago.
**Examples appear in the table below, with explanations


|{{Version badge 1}} Not available in Cumulus 1.
Following the table giving the tag names actually available, there is a section on how to derive a few more weather derivatives using a combination of the tag names shown.


[[File:Badge vMx.png]] see release announcements for version availability


Date and Time of last strike (default without output parameters is locale's short time format e.g. 18:02 or 6:02 pm, without date, but tag accepts both date and time output parameters). Returns '----' if you don't have sensor or there has not been a strike since the sensor was installed. (GW1000 api returns FFFF FFFF seconds after midnight on 01 Jan 1970, which translates to 07/02/2106 06:28:15, so MX translates that to '----')
===Warning when Daylight Saving Time starts or ends===
|-
|<#LightningStrikesToday>


|{{Version badge 1}} Not available in Cumulus 1.
Note that Cumulus uses current time, read from the computer, to determine which array element it stores each value in.  


[[File:Badge vMx.png]] see release announcements for version availability
Hence ''when clocks go back'' the value stored for winter time overwrites the value previously stored for same time during summer time for the relevant repeating hour.  


Number of strikes since midnight, default 0
Hence even if you use 10am for your rollover time in summer, you will not have access to a whole hour worth of data when the clocks change
|-
* ''when the clocks go back'', one hour has been overwritten; or
|<#UserTemp1>
* ''when the clocks go forward'', one hour in the array simply does not exist.


|{{Version badge 1}} Not available in Cumulus 1.
=== Table of Recent History web tags available ===
 
[[File:Badge vMx.png]] see release announcements for version availability
 
User Temperature 1
support for the Ecowitt WH34 (other model types exist and are reported here as if WH34) soil and water temperature sensors
|-
|colspan="2"|... and so on up to <#UserTemp8> = User temperature 8
|}
 
 
Ecowitt stations are sold under other names depending on nation,  e.g. Ambient in USA, Froggit in central Europe, so Ecowitt is used as a generic name in same way as Fine Offset is used elsewhere in this article.
 
==Recent History==
 
There are a set of web tags for 'recent historical data', based on an array stored by Cumulus giving data values from 1 minute ago, up to 1 week ago, in 1 minute intervals. As Cumulus runs it will add the latest values to the array with full resolution, and shift existing values along so those older than 7 days fall off.  Following the table giving the tags actually available, there is a section on how to derive a few more tags.
 
(Note that Cumulus uses current time read from the computer to determine which array element it stores each value in. Hence ''when clocks go back'' the value stored for winter time overwrites the value previously stored for same time during summer time for the relevant repeating hour. Hence even if you use 10am for your rollover time in summer, you will not have access to a whole hour worth of data when the clocks change as either the hour has been overwritten or ''when the clocks go forward'' it simply does not exist).
 
[[#No_Commas]] versions of the array are available for use in script.
 
=== Input Parameters ===
 
You specify which value you want from the array by using parameters on the web tags for number of days ago, hours ago, and minutes ago. The same d, h, and m, parameters are used by Cumulus 1 and MX.
 
All values supplied for parameters must be whole numbers.
 
If you don't supply any parameters, the result is undefined for Cumulus 1, and an illegal web tag for MX.
 
<#RecentOutsideTemp m=1> will give the temperature one minute ago, <#RecentOutsideTemp h=1> will give the temperature one hour ago (as will <#RecentOutsideTemp m=60>).
 
<#RecentOutsideTemp d=1> will give the temperature one day ago. '''Please note:''' Some Cumulus users say that using <#RecentOutsideTemp  d=1 m=1> is more reliable at getting the temperature at a similar time the day before, the extra minute apparently gives better results when you might not be using Cumulus all the time, or your weather station might have some drift on when it supplies readings. See which works best for you.


<#RecentOutsideTemp d=1 h=1 m=1> will give the temperature one day, one hour and one minute ago.


'''Please note that parameters specify time-stamped array element to retrieve based on counting back from current local time''' so the result for ''any period including when clocks change'' may not be quite what you anticipated.
[[#No_Commas]] versions of the array are available for use in script. If you use MX, the tag names in this table can take a [[Webtags/Parameters#Output Modification Parameter for Removing Commas|rc=y]] parameter.
 
 
=== During catch-up ===
When Cumulus is re-started the array it sets up will be based on reading the logs, so the contents will initially have a resolution according to the logger interval you have set in Cumulus and/or your station. You'll get the nearest value if you ask for a time for which there is currently no exact match, and the first tag listed tells you that nearest time.
 
=== Variations between Builds/Versions ===
Before build 1098, the recent history array did not initialise correctly from the station logger for the period since Cumulus was last run.
 
The input parameters are same for Cumulus 1 and Cumulus MX, they always use lower case d, h or m.
 
The list of tags available has not changed between last Cumulus 1 release and any MX release. Any new derivatives reported elsewhere have not resulted in equivalent new recent history tags.
 
=== Table of Recent History web tags available ===


{| class="wikitable" border="1"
{| class="wikitable" border="1"
Line 2,474: Line 1,968:
This table includes web tags that show the values in [[Monthlyalltime.ini]] log file, which was introduced in version 1.9.3 (build 1033, 10 Apr 2012).
This table includes web tags that show the values in [[Monthlyalltime.ini]] log file, which was introduced in version 1.9.3 (build 1033, 10 Apr 2012).


These are a set of tags for monthly all-time highs and lows, in other words the highest and lowest values for a particular month of the year.  To supply both optional input, and optional output parameters, separate them with spaces, e.g. <#ByMonthTempHT mon=7 format=hh:nn>. In that example,  the highest ever temperature in July is returned in the value after processing by Cumulus.
These are a set of tags for monthly all-time highs and lows, in other words the highest and lowest values for a particular month of the year.  To supply both optional input modification, and optional output modification parameters, separate them with spaces, e.g. <#ByMonthTempHT mon=7 format=hh:nn>. In that example,  the highest ever temperature in July is returned in the value after processing by Cumulus.
 
Each Monthly All Time Records web tag has an optional input parameter "mon=N" where N is the index of the month of the year that you want the value for (January=1 and so on).  The corresponding date/time web tags are formatted like the all time records directly above this section. You can customise the date and time formats using the output  'format' parameter on the web tag.


If you don't supply an input parameter (or supply an invalid value like zero) the current month will be used. This is useful if you want to write a template that will always supply values for the current month and don't want to use a script to enter the correct input parameter by processing with that script before Cumulus processes the template.
For full details of the input modification parameters, see [[Webtags/Parameters#Input_modification_Parameters|Parameters]] page.


Additional tags correctly populated from 3.6.10 (build 3086) or 3.7.0 (build 3089) are marked with a "MX" icon as they are not available in Cumulus 1. Please note the 3.6.10 release was available from 24 June 2020, if the date/time shown for those MX only tags is before when you installed that (or a later release), the feels like output may show incorrect values.
Additional tags correctly populated from 3.6.10 (build 3086) or 3.7.0 (build 3089) are marked with a "MX" icon as they are not available in Cumulus 1. Please note the 3.6.10 release was available from 24 June 2020, if the date/time shown for those MX only tags is before when you installed that (or a later release), the feels like output may show incorrect values.
Sfws
5,838

edits

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

Navigation menu