Webtags (preserving history): Difference between revisions

From Cumulus Wiki
Jump to navigationJump to search

Webtags (preserving history) (view source)

Revision as of 13:06, 31 May 2022

1,274 bytes added ,  13:06, 31 May 2022
m
→‎Day/Night/Sun/Moon
(28 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[Category:Terminology]]
[[Category:Terminology]]
=Some content has been removed from this page=
Please be aware some content originally on this page has been moved to other pages.  Old posts on the support forum that used to link directly to the specific material, will instead bring you to this start of the page.  
Please be aware some content originally on this page has been moved to other pages.  Old posts on the support forum that used to link directly to the specific material, will instead bring you to this start of the page.  


The new links to material that has been moved off this page can be found approximately where the material used to be within two sections on this page: [#Input Modification Parameters and Output Modification Parameters]] and  [[#The tag name]].
Where the old content was cut, new links have been substituted within three sections on this page: [[#Input Modification Parameters and Output Modification Parameters]], [[#The tag name]], and [[#Recent History]].


=Essential Background Reading=
=Essential Background Reading=
Line 8: Line 10:
If you have not used this Wiki page before, or are unsure about using "web tags", there are some concepts that you do need to understand in the sub-sections that follow.
If you have not used this Wiki page before, or are unsure about using "web tags", there are some concepts that you do need to understand in the sub-sections that follow.


[[File:Badge v1.png]][[Category:Cumulus 1]] This page was created for Cumulus 1. Steve/Beth Loft provided some example [[Cumulus template file|web template files]], but expected Cumulus users to develop their [[Customised templates|own Cumulus template files]] making use of the web tags, listed below, that the software provided.
===The tag names===


Early releases of MX also followed that [[Customised templates|web page template files you could customise]] approach, but that has now stopped.
<div style="background: LemonChiffon;padding:5px; margin:2px;">All the "tag_names" that are available for legacy 1.9.4, and for MX up to first beta build release '''3.12.0'''</div>  are in [[#Full List of Tag Names]] later on this page.
<div style="background: LemonChiffon;padding:5px; margin:2px;">
[[File:Crystal Clear info.png|40px]]  


USING CURRENT RELEASE OF MX?
<big>If you edit this page, to add tag names for later builds, please amend the previous sentence.</big>
* Go to <big>[[WebsitedataT.json]]</big> page, instead of this one
* That page explains the ID names used on the [[New_Default_Web_Site_Information|default web site]] introduced from release 3.10.0
* That page documents each data pair in the file
* That page gives the source web tag for each ID name on the web pages
* That page explains what data is represented by the  ID name, JSON attribute, web tag name


Continue reading this Wiki Page if you are using your own (customised) web pages, using legacy web pages, ''or'' want a definitive list of all available web tags.
If you are using a Oregon Scientific weather station, then you should read [[#Web tags mentioning (outside) temperature]] in the optional reading section.
</div>
{{TOCright}}
==What is a web tag? ==


Weather values are always changing, so Cumulus needs a way for you to tell Cumulus to enter the current value for a particular derivative, when it is [[Customised_templates#What_is_meant_by_.27Cumulus_processes_templates.27|processing templates]].
Do not assume that Cumulus always works according to normal meteorological practice in your nation.  For examples, the hours used by Cumulus to report derivatives involving rainfall, or minimum temperature, may vary from figures reported by local meteorological stations.
 
==General Format for Web Tags==


In the position, in any template file, SQL, or Custom HTTP, where Cumulus is to insert the relevant data, place a web tag in the '''general format''' specified here:  <code><#tag_name [optional input selection parameters] [optional output modification parameters]></code>
===Quick summary of MX and Legacy differences===


===The optional parameters===
==Cumulus MX versus original Legacy Cumulus 1==


The terminology "optional" is used because some tag names do not accept any parameters, but there are some tag names where a parameter is mandatory. Therefore, check the [[Webtags/Parameters|web tag parameters]] page to learn whether a web tag name you find here requires a mandatory parameter, or to find out which parameters are optionally available.
The full information that used to appear on this page for differences between MX and the legacy Cumulus has been moved to a new [[Webtag Applicability|Web tag Applicability page]].  The next subsection just gives a basic summary.


The tables of tag names that appear later on this page will seldom give any information about which parameters are mandatory or optional. There are tables on the other page referenced above that help you to understand what parameters the various tag names accept, explain each of the parameters available, and give examples.
[[File:Badge vMx.png]] This page has been updated to include web tags up to version 3.12.0 beta build 3134.  Announcements for new builds of MX generally provide too little information for it to be easy to update this page, that is why it is often out of date.
* Since version 3.10.x, MX has not used web page templates, please see <big>[[WebsitedataT.json]]</big> page, instead of this Wiki page.
*# That page explains the ID names used on the [[New_Default_Web_Site_Information|default web site]] introduced from release 3.10.0
*# That page documents each data pair in the file
*# That page gives the source web tag for each ID name on the web pages
*# That page explains what data is represented by the ID name, JSON attribute, web tag name
* Past MX releases 3.0.0 to 3.9.7 used [[Cumulus template file|web template files]], similar to (but not same as) the legacy software
** This Wiki page remains organised according to the content of those old template files.


There is a basic guide to what these parameters can do, and another link to the new page at [[#Input Modification Parameters and Output Modification Parameters]] later on this page.
[[File:Badge v1.png]][[Category:Cumulus 1]] This page was created for Cumulus 1. Steve/Beth Loft provided some example [[Cumulus template file|web template files]], but expected Cumulus users to develop their [[Customised templates|own Cumulus template files]] making use of the web tags, listed below, that the software provided.


For tag names available in the release you are using, see the next sub-sections.


===The tag names===
===What web tags can I use?===


<div style="background: LemonChiffon;padding:5px; margin:2px;">All the "tag_names" that are available for legacy 1.9.4, and for MX up to release '''3.12.0'''</div>  are in [[#Full List of Tag Names]] later on this page.
Basically, it depends on which web tags are in whatever files are used to transfer weather derivatives to your web server.


As Cumulus has developed, more tag names have been introduced, the tables showing tag names available, attempt to give an indication of which release introduced them. The information that used to appear on this page for differences between MX and the legacy Cumulus has been moved to a new [[Webtag Applicability|Web tag Applicability page]].
As Cumulus has developed, more tag names have been introduced, the tables showing tag names available, attempt to give an indication of which release introduced them. You can, see below, ask Cumulus (both MX and legacy) to list all the tag names it recognises, when it is started at whatever build you are running.


For tag names available in the release you are using, see the next sub-section.


If you are using a Oregon Scientific weather station, then you should read [[#Web tags mentioning (outside) temperature]] in the optional reading section.


====Inconsistency of tag names====
====Using release after 3.9.7?====


For both the legacy Cumulus and for MX, it is vital that you use tag names exactly as they are listed. That would be easy had Steve Loft created a naming standard and stuck to it. To be fair, when he first created tag names, Cumulus could only report current values and the summary for the day so far; Steve did not anticipate, back then, that later he would add extreme record monitoring. The legacy tag names for this month and this year were all introduced in a single release and they remain consistent apart from what MX added later!  However, they are not consistent with the naming of the all-time extremes introduced much earlier.
If you are using the [[New_Default_Web_Site_Information|default web site]], its standard web pages show data as follows:
* Pages with tabular presentation, see [[WebsitedataT.json]].
* Pages with graphs, see [[Cumulus.ini#Optional_Web_Server|Graph File Settings]].
* Page with steel series dials, see  [[Cumulus.ini#Display_Options|Display Options]].


This great inconsistency in the naming, gives rise to a problem as it very easy to spell a tag_name incorrectly (and I apologise if any such mistakes creep into the tables) as you naturally expect there to be a standard pattern.  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.  
If you are using your own web templates, or other [[Customised templates|own Cumulus template files]] such as [[Php_webtags|XML or PHP data files]], then you make the decision on which tag names are used for the data to your web server.




=====Inconsistency in use of "Y"=====
====Getting release 3.12.0 or later to list tag names when it starts====


The character "Y" has been selected to denote yesterday in tag names.  The inconsistency is where it appears.  In his oldest tag names (e.g. <#rfallY>, <#windrunY>, <#avgtempY>), Steve used this Y as a suffix. In newer tag names (e.g. <#Ybeaufort>, <#YSunshineHours>, <#Ychillhours>), Steve changed to using Y as a prefix.
Please use the admin interface.


=====Consistency becomes inconsistency for this month and this year=====
Go to '''Program settings → General options'''


The legacy tag names for this year and this month were all introduced together by Steve in one release, with consistency in how they were named then, "Month" or "Year" was used as a prefix (this was after he had started using "Y" as a prefix for his new yesterday tag names) e.g. <#YearLongestDryPeriod>.
Tick ''List web tags''.


The development of MX broke this consistency, as Mark adds "Year" as a suffix e.g. <#SunshineHoursYear>.
The next time that MX is restarted, 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.  


=====Inconsistency in use of "T"=====
Go to '''Program settings → General options''', untick ''List web tags'' to stop Cumulus continuing to produce new versions of that file next time it is restarted.


I said above, that early versions of Cumulus only had tag names for current values and for today-so-far.  Therefore it could be assumed that <#beaufort>,  <#temp> and <#press> all represented current values while <#avgtemp> and <#rfall> represented today-so-far values just by looking at their names.


The current value tag names could be used as the basic part of tag names with  "TH" and "TL" added as suffixes to represent daily highs and daily lows, (e.g. <#tempTH>, <#tempTL> and <#pressTH>, <#pressTL>), which made a lot of sense.
====Getting legacy Cumulus, or MX releases up to 3.11.4, to list tag names when starting====
 
But that naming convention was broken when the extreme <#Tbeaufort> used "T" as a prefix, not suffix, and did not include a "H". Continuing looking at today-so-far tag names, we discover a prefix "T" is not just used for values, it is also used for time-stamps e.g. <#TtempTH>.
 
The use of "T" as a prefix for time-stamps continues in the tag names for all-time extreme records. However, when you look at time-stamps for extremes in this-year, the time-stamp denoting "T" is added as a suffix e.g. <#YearTempHT>.
 
====General Tip====
 
''This sub-section applies to releases up to 3.11.4.'' (From 3.12.0, use the admin interface and Program settings → General options, to get to where you change this setting, instead of editing the file as described below).


The tag names available in the release/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 tag names available in the release/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...
Line 94: Line 84:
[[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: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.


===The functionality that can use web tags===
==What is a web tag? ==


In the legacy Cumulus software, the only functionality that could use this was [[#Template files can create many types of file|the Cumulus template file]] used to provide data to a web server. That is why Steve Loft, the author of that software named them web tags.
Weather values are always changing, so Cumulus needs a way for you to tell Cumulus to enter the current value for a particular derivative, when it is [[Customised_templates#What_is_meant_by_.27Cumulus_processes_templates.27|processing templates]].
MX has extended the use of these web tags, they can now be inserted into a [[MX_Administrative_Interface#MySQL_settings|SQL commands]], Custom HTTP, [[#The web tag application programming interface|application programming interface]], as well as [[#Template files can create many types of file|template files]].


The output file can be:
==General Format for Web Tags==
* 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.


=Optional Background Reading=
In the position, in any (HTML, JSON, PHP, XML) template file, SQL, or Custom HTTP, where Cumulus is to insert the relevant data, place a web tag in the '''general format''' specified here:  <code><#tag_name [optional input selection parameters] [optional output modification parameters]></code>
 
===The optional parameters===
 
The terminology "optional" is used because some tag names do not accept any parameters, but there are some tag names where a parameter is mandatory. Therefore, check the [[Webtags/Parameters|web tag parameters]] page to learn whether a web tag name you find here requires a mandatory parameter, or to find out which parameters are optionally available.
 
The tables of tag names that appear later on this page will seldom give any information about which parameters are mandatory or optional.  There are tables on the other page referenced above that help you to understand what parameters the various tag names accept, explain each of the parameters available, and give examples.


==Web tags mentioning (outside) temperature==
There is a basic guide to what these parameters can do, and another link to the new page at [[#Input Modification Parameters and Output Modification Parameters]] later on this page.


'''For Oregon Scientific weather stations using, either USB connections''' (e.g. WMR-200), or serial connections (e.g. WMR-928), that can have multiple temperature sensors, it is possible to configure which sensor the outdoor temperature (for which daily and longer period extreme records are maintained) is read from, by following this set of instructions originally supplied by Steve Loft:
# Stop Cumulus in the normal way
# Use a text editor to edit the file called ''Cumulus.ini''
# Scroll down to the line that contains '''[Station]'''
# Create a blank line below it by pressing ''Return''
# In that new line, type the command shown in the relevant code box below, type the attribute and equals sign exactly as shown without spaces (regardless of your exact model),
#* USB connections &rarr; <code>WMR200TempChannel=N</code>
#* Serial connections &rarr; <code>WMR928TempChannel=N</code>
# Now edit the value shown after the equals sign, replace ''N'' with the relevant number from the following list:
#* To use the main sensor, replace N with '''0''' (or don't bother with this procedure, as that is default)
#* To use Extra Temp 1 sensor, replace N with '''1'''
#* To use Extra Temp 2 sensor, replace N with '''2'''
#* and so on, up to a possible maximum (check with your weather station, but Cumulus can accept up to 12)
# Save the file, and exit
# Restart Cumulus in the normal way




'''For other weather stations''', the main outdoor temperature sensor is used for what is reported for current value, daily extremes, and longer period extreme records.  This temperature is also used for calculation of derived values such as Australian Apparent Temperature, Canadian Humidity Index, and USA Heat Index.
===Inconsistency of tag names===


==Input Modification Parameters and Output Modification Parameters==
For both the legacy Cumulus and for MX, it is vital that you use tag names exactly as they are listed.  That would be easy had Steve Loft created a naming standard and stuck to it.


In [[#Scary_statistics]] section of this page, it is explained how less than a thousand [[#Full List of Tag Names|tag names]] (the first part of the [[#General Format for Web Tags]]) become billions of web tags, simply by adding modifiers.
To be fair to Steve, he created the legacy Cumulus for his own use, working in his spare time, alongside a full time job.


The modifiers available used to be listed on this page (so if you select the history tab for this page, you will find references to their introduction and growth), but are now on a new [[Webtags/Parameters|web tag parameters]] page.  Here are some of the advantages achieved by moving them to the new page:
Remember, the original design did not anticipate use by others, nor how much extra functionality would be added later.
* This page is very long, so it is not easy to navigate this page, even without the parameters
* There would be a lot of repetition if you attempted to say beside each tag name which modification parameters were available.
* Having them on separate pages means you can have two tabs (or two separate browsers) open so you can see both the tag name and the modifier parameter by flicking between tabs, instead of lots of scrolling between different parts of same page.
* The introduction of [[WebsitedataT.json]], which controls what data is available to tables in the web pages provided by MX, means that page, rather than this page is the entry point for MX, and it is easier for that page to reference a separate parameters page
* MX has introduced many more input and output modification parameters, it is easier to maintain a separate page (and easier for reference if you just want to refresh your mind on new modification parameters).


Early versions of Cumulus could only report current values and the summary for the day so far.  Different web tags for today-so-far were added at different times, hence the names are inconsistent. New web tags for today-so-far added before yesterday tags were considered lack the T suffix (or prefix) later today-so-far tags use.


For just a taste, there you can discover:
All-time tags were introduced before yesterday, this month and this year; hence all-time tag names assume they are only extreme monitoring.
* A score of [[Webtags/Parameters#Input_modification_Parameters|input modification parameters
** For  example, find which attribute is used with a value between 1 and 12, so the same tag name can give values for 12 different months)
* If your locale normally (in real numbers) uses an integer part, then a comma, and then the decimal part, you should be aware that some computer scripts, and some external servers where you might want to send data, insist on a decimal point, instead of a decimal comma:
** If you have installed a recent MX release, then [[Webtags/Parameters#Output_Modification_Parameter_for_changing_any_decimal_comma_into_a_decimal_point|change decimal comma to decimal point]] with a simple "y" value to another attribute
** If you have the legacy Cumulus 1 installed, stay on this page and look at [[#No_Commas]], as you have to use the restricted alternative set of tag names.
* How to [[Webtags/Parameters#Two_Output_.28format_modifier.29_parameters_for_decimal_places|control number of decimal places]] in any real number output
* All about the complex subject of modifying the way a '''duration''', a ''date'', or a  '''clock time''' is output by looking [[Webtags/Parameters#Multiple_Output_Format_Modifier_parameters_for_times_and_dates|here]]


== Why does MX talk about tokens? ==
The legacy tag names for this month and this year were all introduced in a single release and they remain consistent apart from what MX added later!  However, they are not consistent with the naming of the all-time extremes introduced much earlier.


MX uses a [[Cs_Code_Modules#TokenParser.cs|'''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.
This great inconsistency in the naming, gives rise to a problem as it very easy to spell a tag_name incorrectly (and from time to time such mistakes creep into the tables on this Wiki page) as you naturally expect there to be a standard pattern.  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.  


==Scary statistics==


# The 3.5.0 release of MX defines 9½ million values that can be represented using '''web tags'''!
=====Inconsistency in use of "Y"=====
# At 3.5.0, there are only 717 options for the '''tag_name''' in the general format given above.
# How come this discrepancy?
# That discrepancy is purely because some of those 717 tag names can be associated with input parameters, (and for Oregon Scientific stations,you can select which sensor is used for outside temperature), these modifications affect what value is selected to be output by the web tag leading to the large number
# These millions of web tags can actually produce billions of different outputs!
# How come this second discrepancy?
# Well adding all possible different output parameters generates the billions of different ways to output the millions of values!
The statistics quoted above keep increasing as MX is developed, the last time I checked, there were another forty or so tag names, and lots more parameters, so the alternatives are probably well over ten billion now.


== Brief history of this page==
The character "Y" has been selected to denote yesterday in tag names.  The inconsistency is where it appears. 


This page was created in August 2009, to list the tags for the (legacy) Cumulus 1 software.  Initially, there were going to be further pages to explain individual web tags, e.g. [[Forecast_webtag]]; but that idea was never completed. 
* Steve used Y as a suffix for most, not all, Cumulus 1 yesterday tags (e.g. <#rfallY>, <#windrunY>, <#YSunshineHours>, <#avgtempY>)
* Mark uses Y as a prefix, in most, not all, the extra Cumulus MX tags (e.g. <#Ybeaufort>, <#Ychillhours>, <#windAvgY>)


When MX came out of beta (3.0.0), it has been developing rapidly, as the statistics above suggest, the number of web tag names and input/output modification parameters, to document became too much for one Wiki page, hence the moving of all documentation about modification parameters to a sub-page.  There are still a lot of web tag names to document on this page, and separation into a number of pages was considered, but it is easier to have just one page to refer in answers to questions raised in the forum.
=====Consistency in Cumulus 1, becomes inconsistency in MX, for this month and this year=====


==Still got questions?==
The legacy tag names for this year and this month were all introduced together by Steve in one release, with consistency in how they were named then, "Month" or "Year" was used as a prefix (this was after he had started using "Y" as a prefix for his new yesterday tag names) e.g. <#YearLongestDryPeriod>.


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.
The development of MX however, broke this consistency, as Mark adds "Year" as a suffix, e.g. <#SunshineHoursYear>, instead of following Steve by using a prefix.


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.
=====Inconsistency in use of "T"=====


==The web tag application programming interface==
I said above, that early versions of Cumulus only had tag names for current spot values and for today-so-far daily means/extremes/totals.  Therefore it could be assumed that <#beaufort>,  <#temp> and <#press> all represented current spot values while <#avgtemp> and <#rfall> represented today-so-far values just by looking at their names.


[[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].
The current value tag names formed the basic part of tag names, extended for daily extremes with  "TH" and "TL" added as suffixes (to represent daily highs and daily lows), (e.g. <#tempTH>, <#tempTL> and <#pressTH>, <#pressTL>), which made a lot of sense. Adding a "T" for related times, made some sense, except that use of "T" was not done in a consistent manner (e.g. <#TpressTH>, <#Tbeaufort>,  <#TtempTH>, <#YearTempHT>).


=== 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 functionality that can use web tags===


The [[Cumulus_MX_Local_API|MX Administrative Interface]] uses some application programming interface (api) calls to obtain the data each web page in that interface needs, and if you are making an edit, another api to return the results of any edit made.  
In the legacy Cumulus software, the only functionality that could use this was [[#Template files can create many types of file|the Cumulus template file]] used to provide data to a web server. That is why Steve Loft, the author of that software named them web tags.
MX has extended the use of these web tags, they can now be inserted into a [[MX_Administrative_Interface#MySQL_settings|SQL commands]], Custom HTTP, [[#The web tag application programming interface|application programming interface]], as well as [[#Template files can create many types of file|template files]].


If you wanted your '''CumulusMX/interface/todayyest.html''' web page to include something else (e.g. snow falling/lying/depth) you could edit that HTML page to have the extra sub-table you want (you cannot edit the existing rainfall table as that is dynamically created by existing api). Then you could 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.
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.


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.
=Optional Background Reading=
 
==Web tags mentioning (outside) temperature==


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.
'''For Oregon Scientific weather stations using, either USB connections''' (e.g. WMR-200), or serial connections (e.g. WMR-928), that can have multiple temperature sensors, it is possible to configure which sensor the outdoor temperature (for which daily and longer period extreme records are maintained) is read from, by following this set of instructions originally supplied by Steve Loft:
# Stop Cumulus in the normal way
# Use a text editor to edit the file called ''Cumulus.ini''
# Scroll down to the line that contains '''[Station]'''
# Create a blank line below it by pressing ''Return''
# In that new line, type the command shown in the relevant code box below, type the attribute and equals sign exactly as shown without spaces (regardless of your exact model),
#* USB connections &rarr; <code>WMR200TempChannel=N</code>
#* Serial connections &rarr; <code>WMR928TempChannel=N</code>
# Now edit the value shown after the equals sign, replace ''N'' with the relevant number from the following list:
#* To use the main sensor, replace N with '''0''' (or don't bother with this procedure, as that is default)
#* To use Extra Temp 1 sensor, replace N with '''1'''
#* To use Extra Temp 2 sensor, replace N with '''2'''
#* and so on, up to a possible maximum (check with your weather station, but Cumulus can accept up to 12)
# Save the file, and exit
# Restart Cumulus in the normal way


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 ===
'''For other weather stations''', the main outdoor temperature sensor is used for what is reported for current value, daily extremes, and longer period extreme records.  This temperature is also used for calculation of derived values such as Australian Apparent Temperature, Canadian Humidity Index, and USA Heat Index.


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.
'''''Please check release announcements, it is planned that swaping of main Temperature sensor will become available for Ecowitt.'''''
Full List of Tag Names
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.


====Selecting values using GET====
==Input Modification Parameters and Output Modification Parameters==


Suppose you want to get the values for the following three web tags:
In [[#Scary_statistics]] section of this page, it is explained how less than a thousand [[#Full List of Tag Names|tag names]] (the first part of the [[#General Format for Web Tags]]) become billions of web tags, simply by adding modifiers.
# <#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:
The modifiers available used to be listed on this page (so if you select the history tab for this page, you will find references to their introduction and growth), but are now on a new [[Webtags/Parameters|web tag parameters]] page.  Here are some of the advantages achieved by moving them to the new page:
<pre>sudo mono CumulusMX.exe -port 9999</pre>
* This page is very long, so it is not easy to navigate this page, even without the parameters
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'''
* There would be a lot of repetition if you attempted to say beside each tag name which modification parameters were available.
* Having them on separate pages means you can have two tabs (or two separate browsers) open so you can see both the tag name and the modifier parameter by flicking between tabs, instead of lots of scrolling between different parts of same page.
* The introduction of [[WebsitedataT.json]], which controls what data is available to tables in the web pages provided by MX, means that page, rather than this page is the entry point for MX, and it is easier for that page to reference a separate parameters page
* MX has introduced many more input and output modification parameters, it is easier to maintain a separate page (and easier for reference if you just want to refresh your mind on new modification parameters).




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.
For just a taste, there you can discover:
Remember that in current version (and some earlier versions) of MX, the above three web tags are exactly same as:
* A score of [[Webtags/Parameters#Input_modification_Parameters|input modification parameters]]
# <#temp rc=y>
** For  example, find which attribute is used with a value between 1 and 12, so the same tag name can give values for 12 different months)
# <#hum rc=y>
* If your locale normally (in real numbers) uses an integer part, then a comma, and then the decimal part, you should be aware that some computer scripts, and some external servers where you might want to send data, insist on a decimal point, instead of a decimal comma:
# <#dew rc=y>
** If you have installed a recent MX release, then [[Webtags/Parameters#Output_Modification_Parameter_for_changing_any_decimal_comma_into_a_decimal_point|change decimal comma to decimal point]] with a simple "y" value to another attribute
** If you have the legacy Cumulus 1 installed, stay on this page and look at [[#No_Commas]], as you have to use the restricted alternative set of tag names.
* How to [[Webtags/Parameters#Two_Output_.28format_modifier.29_parameters_for_decimal_places|control number of decimal places]] in any real number output
* All about the complex subject of modifying the way a '''duration''', a ''date'', or a  '''clock time''' is output by looking at [[Webtags/Parameters#Multiple_Output_Format_Modifier_parameters_for_times_and_dates|Multiple_Output_Format_Modifier_parameters_for_times_and_dates]]


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.
== Why does MX talk about tokens? ==


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.
MX uses a [[Cs_Code_Modules#TokenParser.cs|'''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.


==== JavaScript example ====
==Scary statistics==


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.
# The 3.5.0 release of MX defines 9½ million values that can be represented using '''web tags'''!
 
# At 3.5.0, there are only 717 options for the '''tag_name''' in the general format given above.  
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.
# How come this discrepancy?
# That discrepancy is purely because some of those 717 tag names can be associated with input parameters, (and for Oregon Scientific stations,you can select which sensor is used for outside temperature), these modifications affect what value is selected to be output by the web tag leading to the large number
# These millions of web tags can actually produce billions of different outputs!
# How come this second discrepancy?
# Well adding all possible different output parameters generates the billions of different ways to output the millions of values!
The statistics quoted above keep increasing as MX is developed, the last time I checked, there were another forty or so tag names, and lots more parameters, so the alternatives are probably well over ten billion now.


Here is the code (with the api call written using jQuery):
== Brief history of this page==
<pre>/*    Some new variables connected with new api call (MX 3.7.0)  */
var tempLetter;  // C or F
var rainUnit; // mm or in
var windUnit; // any units in style allowed by Cumulus
/*  The one extra api request included to obtain the units used for temperature, rainfall, and wind speed */
$.get('./api/tags/process.json?tempunitnodeg&rainunit&windunit', "limit=1", callUnits);
function callUnits(unitsObject)
{
tempLetter = unitsObject.tempunitnodeg;
rainUnit = unitsObject.rainunit;
windUnit = unitsObject.windunit;
console.log("new api", tempLetter, rainUnit,windUnit);
}</pre>
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
*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
*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
*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)
*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.


=== "POST" approach ===
This page was created in August 2009, to list the tags for the (legacy) Cumulus 1 software.  Initially, there were going to be further pages to explain individual web tags, e.g. [[Forecast_webtag]]; but that idea was never completed. 


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.
When MX came out of beta (3.0.0), it has been developing rapidly, as the statistics above suggest, the number of web tag names and input/output modification parameters, to document became too much for one Wiki page, hence the moving of all documentation about modification parameters to a sub-page.  There are still a lot of web tag names to document on this page, and separation into a number of pages was considered, but it is easier to have just one page to refer in answers to questions raised in the forum.


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. 
==Still got questions?==


The post approach has a few advantages over get:
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.
*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.  
**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.


See https://cumulus.hosiene.co.uk/viewtopic.php?p=145050#p145050 for post example
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.  
<br>


<br>
==The web tag application programming interface==


=<big>Full List of Tag Names</big> =
[[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].
{{Template:WorkInProgressBanner}}


This list only contains the tag_names, don't forget tag_names are only part of the [[#General Format for Web Tags]], for example in a template file you precede the tag name with &lt;, you may need input parameters, you may need output parameters, and you end the full web tag with &gt;.
=== Where to use===


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.
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.


Here follow tables that group the tag names by the basic purpose of the tags listed. There has been confusion in the past of tags appearing in more than one group, can contributors remove any remaining duplication, so future maintenance is easier.
The [[Cumulus_MX_Local_API|MX Administrative Interface]] uses some application programming interface (api) calls to obtain the data each web page in that interface needs, and if you are making an edit, another api to return the results of any edit made.  


There is a table of contents near the top of the page that you might find useful if you are interested in a particular tag group.  
If you wanted your '''CumulusMX/interface/todayyest.html''' web page to include something else (e.g. snow falling/lying/depth) you could edit that HTML page to have the extra sub-table you want (you cannot edit the existing rainfall table as that is dynamically created by existing api). Then you could 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.


==Current Conditions==
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.


We start with tags that relate to the latest values, as these are the ones that people most often choose to use. The current condition data is also available, for processes external to Cumulus, by using the inbuilt facility to generate [[Realtime.txt|a file]] with such data.
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.  


Cumulus software makes current values available for a standard range of sensors where the same web tags apply across a range of weather station models.
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.


Both Cumulus 1 and MX offer current values from some [[#Extra Sensors|extra]] temperature and relative humidity sensors (see [[Extra temperatures]]) from particular weather station models.
=== "GET" approach ===


Recently, MX has been developed to support further extra sensors (see [[Extra Sensor Files]] page for full list of fields) and web tags have been added to support equivalent current values only.  
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.
Full List of Tag Names
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.


==== Feels Like ====
====Selecting values using GET====


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.
Suppose you want to get the values for the following three web tags:
# <#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:
<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'''


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).
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>


The [[Calculate_Missing_Values#CreateMissing.exe| Create Missing utility]] will not correct the older (incorrectly calculated) figures, but will add Feels Like temperature values to any standard log line created by Cumulus 1, by MX prior to release 3.5.4, or if you have imported lines into the log from an external source.
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.


===Standard sensors===
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.


The web tags shown here are mainly determined by which appeared on the original "Now" legacy web page (index.htm).
==== JavaScript example ====


Consequently, the totals for 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.
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.   
   
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 because of differences in the calculation formulae, see derived value section within Recent History tags section for examples.
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.
{| class="wikitable" border="1"
|-
!style="width:150px" | Web tag_name
!style="width:600px" | Function
|-
|colspan="2" style="background:lightgray;"|Temperature
|-
|<#temp>
|The outside (air) temperature


For Oregon Scientific models like WMR-200 with USB connection or models like WMR-928 with serial connections, please refer to [[#Web tags mentioning (outside) temperature]] because any of the [[#Extra Sensors: Davis models and Oregon Scientific WMR928, WR100/200|extra sensors]] can be reported in '''<#temp>''', and consequently also have web tags reporting daily extremes and longer period extreme records.
Here is the code (with the api call written using jQuery):
|-
<pre>/*    Some new variables connected with new api call (MX 3.7.0) */
|<#intemp>
var tempLetter;  // C or F
|The inside temperature
var rainUnit; // mm or in
|-
var windUnit; // any units in style allowed by Cumulus
|<#TempChangeLastHour>
/*  The one extra api request included to obtain the units used for temperature, rainfall, and wind speed */
|The change in outside temperature over the last hour (not available in early versions of Cumulus  1, when this was announced, a temperature change over 24 hours was also proposed, but never implemented)
$.get('./api/tags/process.json?tempunitnodeg&rainunit&windunit', "limit=1", callUnits);
|-
function callUnits(unitsObject)
|<#temptrend>
{
|The average rate of change in temperature over the last three hours. Trend = (temp_now - temp_3hrs_ago) / 3 (available in all releases, the calculation selected for this trend matches the standard-based calculation for <#presstrendval> despite the naming inconsistency)
tempLetter = unitsObject.tempunitnodeg;
|-
rainUnit = unitsObject.rainunit;
|<#temptrendtext>
windUnit = unitsObject.windunit;
|Temperature change over the last three hours - Rising/Falling/Steady (values can be set in strings.ini)
console.log("new api", tempLetter, rainUnit,windUnit);
|-
}</pre>
|<#temptrendenglish>
A little bit of explanation might help:
|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). From version 1.8.8 1st December 2009
*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
|<#heatindex>
*The jQuery get request takes the api URL as first parameter and the function to deal with the returned result as third parameter
|Current [[heat index]].  The referenced page in weather terminology section of this Wiki explains it.
*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
|<#humidex>
*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)
|Current [http://en.wikipedia.org/wiki/Humidex Humidex]
*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).
|<#apptemp>
*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.
|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.  
 
|-
=== "POST" approach ===
|<#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>
|[[File:Badge v1.png]] Not available in Cumulus 1.


[[File:Badge vMx.png]]Not available in all MX versions. Please see [[#Feels_Like|sub-section before this table]] regarding availability by MX versions if you are using a MX version earlier than 3.6.10.
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.


The current [[Feels_Like|Feels Like]] temperature.  The referenced page in weather terminology section of this Wiki explains it.
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. 
|-
 
|<#IsFreezing>
The post approach has a few advantages over get:
|If outside temperature is at or below 0°C/32°F. 0=Above freezing, 1=Below freezing
*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.  
|<#chillhours>
**The get approach may be seen when you are navigating through a web site, and a selection is being remembered.
|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).
*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.
|colspan="2" style="background:lightgray;"|Humidity
 
|-
See https://cumulus.hosiene.co.uk/viewtopic.php?p=145050#p145050 for post example
|<#hum>
<br>
|The outside [http://en.wikipedia.org/wiki/Humidity humidity]
 
|-
<br>
|<#inhum>
 
|The inside humidity
=<big>Full List of Tag Names</big> =
|-
{{Template:WorkInProgressBanner}}
|<#dew>
 
|The current dew point
This list only contains the tag_names, don't forget tag_names are only part of the [[#General Format for Web Tags]], for example in a template file you precede the tag name with &lt;, you may need input parameters, you may need output parameters, and you end the full web tag with &gt;.
|-
 
|<#wetbulb>
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.
|Estimated [http://en.wikipedia.org/wiki/Wet_bulb wet bulb] temperature, can be seen if hover over 'Dewpoint' on Cumulus 1 main screen
 
|-
Here follow tables that group the tag names by the basic purpose of the tags listed. There has been confusion in the past of tags appearing in more than one group, can contributors remove any remaining duplication, so future maintenance is easier.
|colspan="2" style="background:lightgray;"|Rainfall
 
|-
There is a table of contents near the top of the page that you might find useful if you are interested in a particular tag group.  
|<#rfall>
 
|The total rainfall so far today
==Current Conditions==
|-
 
|<#rrate>
We start with tags that relate to the latest values, as these are the ones that people most often choose to use. The current condition data is also available, for processes external to Cumulus, by using the inbuilt facility to generate [[Realtime.txt|a file]] with such data.
|The current rainfall rate
 
|-
Cumulus software makes current values available for a standard range of sensors where the same web tags apply across a range of weather station models.
|<#rhour>
 
|The rainfall in the last hour
Both Cumulus 1 and MX offer current values from some [[#Extra Sensors|extra]] temperature and relative humidity sensors (see [[Extra temperatures]]) from particular weather station models.
|-
 
|<#rmidnight>
Recently, MX has been developed to support further extra sensors (see [[Extra Sensor Files]] page for full list of fields) and web tags have been added to support equivalent current values only.
|The total rainfall since midnight. Useful if you don't use midnight as your start of day
 
|-
==== Feels Like ====
|<#r24hour>
 
|Amount of rain in the last 24 hours
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.
|-
 
|<#LastRainTipISO>
 
|Fixed ISO format output giving date and time of last rain gauge tip (e.g 2010-09-06 06:09) The format is always as shown (cannot use output format modifiers)
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).
 
The [[Calculate_Missing_Values#CreateMissing.exe| Create Missing utility]] will not correct the older (incorrectly calculated) figures, but will add Feels Like temperature values to any standard log line created by Cumulus 1, by MX prior to release 3.5.4, or if you have imported lines into the log from an external source.
 
===Standard sensors===
 
The web tags shown here are mainly determined by which appeared on the original "Now" legacy web page (index.htm).
 
Consequently, the totals for 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 because of differences in the calculation formulae, see derived value section within Recent History tags section for examples.
{| class="wikitable" border="1"
|-
|-
|<#LastRainTip>
!style="width:150px" | Web tag_name
| (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'''
!style="width:600px" | Function
|-
|-
|<#MinutesSinceLastRainTip>
|colspan="2" style="background:lightgray;"|Temperature
|The number of minutes since the last rain gauge tip, in whole numbers, rounded down
|-
|-
|<#IsRaining>
|<#temp>
|For [[Rain_measurement#Optical_Rain_Gauge| Hydreon RG-11 devices]], shows the current rain state. 0=No rain, 1=It's raining
|The outside (air) temperature
 
For Oregon Scientific models like WMR-200 with USB connection or models like WMR-928 with serial connections, please refer to [[#Web tags mentioning (outside) temperature]] because any of the [[#Extra Sensors: Davis models and Oregon Scientific WMR928, WR100/200|extra sensors]] can be reported in '''<#temp>''', and consequently also have web tags reporting daily extremes and longer period extreme records.
|-
|-
|<#rmonth>
|<#intemp>
|The total rainfall so far this month
|The inside temperature
|-
|-
|<#ryear>
|<#TempChangeLastHour>
|Annual rainfall total for rainfall season year (i.e. starting month as set on Configuration menu, station screen, Annual rainfall frame)
|The change in outside temperature over the last hour (not available in early versions of Cumulus  1, when this was announced, a temperature change over 24 hours was also proposed, but never implemented)
|-
|-
|<#ConsecutiveRainDays>
|<#temptrend>
|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).
|The average rate of change in temperature over the last three hours. Trend = (temp_now - temp_3hrs_ago) / 3 (available in all releases, the calculation selected for this trend matches the standard-based calculation for <#presstrendval> despite the naming inconsistency)
|-
|-
|<#ConsecutiveDryDays>
|<#temptrendtext>
|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
|Temperature change over the last three hours - Rising/Falling/Steady (values can be set in strings.ini)
|-
|-
|colspan="2" style="background:lightgray;"|Pressure
|<#temptrendenglish>
|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). From version 1.8.8 1st December 2009
|-
|-
|<#press>
|<#heatindex>
|The [http://en.wikipedia.org/wiki/Sea_level_pressure sea level pressure]
|Current [[heat index]]. The referenced page in weather terminology section of this Wiki explains it.
|-
|-
|<#presstrendval>
|<#humidex>
|The average rate of pressure change over the last three hours.  Trend = (pressure_now - pressure_3hrs_ago) / 3    (Fixed from version 1.7.7 5th March 2008)
|Current [http://en.wikipedia.org/wiki/Humidex Humidex]
|-
|-
|<#presstrend>
|<#apptemp>
|The pressure trend in words - values can be set in the 'strings.ini' file
|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.  
|-
|-
|<#presstrendenglish>
|<#wchill>
| 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). From version 1.8.8 1st December 2009
|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.
|-
|-
| <#PressChangeLast3Hours>
|<#feelslike>
|[[File:Badge vMx.png]] Available from version 3.11.1
|[[File:Badge v1.png]] Not available in Cumulus 1.
 
[[File:Badge vMx.png]]Not available in all MX versions. Please see [[#Feels_Like|sub-section before this table]] regarding availability by MX versions if you are using a MX version earlier than 3.6.10.


Total Pressure Change since 3 hours ago
The current [[Feels_Like|Feels Like]] temperature.  The referenced page in weather terminology section of this Wiki explains it.
|-
|<#IsFreezing>
|If outside temperature is at or below 0°C/32°F. 0=Above freezing, 1=Below freezing
|-
|-
|<#altimeterpressure>
|<#chillhours>
|Altimeter pressure. Pressure corrected to sea level using the station's altitude only. Same as sea-level pressure for non-Davis stations.
|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;"|Wind
|colspan="2" style="background:lightgray;"|Humidity
|-
|-
|<#wlatest>
|<#hum>
|Current wind speed reading from console. Corresponds to 'latest' on the Cumulus main screen.
|The outside [http://en.wikipedia.org/wiki/Humidity humidity]
|-
|-
|<#bearing>
|<#inhum>
|Current wind bearing in degrees
|The inside humidity
|-
|-
|<#currentwdir>
|<#dew>
|Current wind bearing as a compass point - e.g. ESE
|The current dew point
|-
|-
|<#wspeed>
|<#wetbulb>
|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.
|Estimated [http://en.wikipedia.org/wiki/Wet_bulb wet bulb] temperature, can be seen if hover over 'Dew point' on Cumulus 1 main screen
|-
|-
|<#avgbearing>
|colspan="2" style="background:lightgray;"|Rainfall
|Average wind bearing in degrees over last configured interval minutes. Range 1-360, 0=Calm
 
This is calculated by taking the wind direction and speed for the last 10 minutes (or other interval as configured), calculates the sums of the North/South and East/West vector components, divides the E/W component sum by the N/S component sum, and takes the arctan.
|-
|-
|<#wdir>
|<#rfall>
|Average wind bearing over last 10 minutes as a [http://en.wikipedia.org/wiki/Compass compass] point - e.g. ESE
|The total rainfall so far today (reports rain counter now minus rain counter at start of day), start of day counter can be edited using "edit rain today".
|-
|-
|<#wgust>
|<#rrate>
|The highest wind reading in the last 10 minutes. Corresponds to 'gust' on the Cumulus main screen.
|The current [[Rain_measurement#Rain_Rate|rainfall rate]]
|-
|-
|<#wdirdata>
|<#rhour>
|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.
|The rainfall in the last hour
|-
|-
|<#wspddata>
|<#rmidnight>
|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''' tag. Reading interval x varies by station type.
|The total rainfall since midnight. Useful if you don't use midnight as your start of day
|-
|-
|<#nextwindindex>
|<#r24hour>
|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!
| Reading recent history records, takes rain counter for latest minute, and substracts rain counter from as close as possible to same time yesterday (if Cumulus was not running at that time yesterday, but historical catch-up has been enabled, then it is from nearest time available yesterday, so for a logging interval of every 30 minutes might be 24 hours and 16 minutes ago)
|-
|-
|<#beaufort>
|<#LastRainTipISO>
|The current wind speed on the [http://en.wikipedia.org/wiki/Beaufort_scale Beaufort scale] (e.g. F8)  
|Fixed ISO format output giving date and time of last rain gauge tip (e.g 2010-09-06 06:09) The format is always as shown (cannot use output format modifiers)
|-
|-
|<#beaufortnumber>
|<#LastRainTip>
|The current wind speed on the Beaufort scale, without a leading "F", e.g. "6"
| (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'''
|-
|-
|<#beaudesc>
|<#MinutesSinceLastRainTip>
|The current wind speed Beaufort description (e.g. "Gale")
|The number of minutes since the last rain gauge tip, in whole numbers, rounded down
|-
|-
|<#BearingRangeFrom>
|<#IsRaining>
|The 'lowest' clockwise bearing in the last 10 minutes (or as configured using AvgBearingMinutes in cumulus.ini)
|For [[Rain_measurement#Optical_Rain_Gauge| Hydreon RG-11 devices]], shows the current rain state. 0=No rain, 1=It's raining
|-
|-
|<#BearingRangeTo>
|<#rmonth>
|The 'highest' clockwise bearing in the last 10 minutes (or as configured using AvgBearingMinutes in cumulus.ini)
|The total rainfall so far this month
|-
|-
|<#BearingRangeFrom10>
|<#ryear>
|The 'lowest' clockwise bearing in the last 10 minutes (or as configured using AvgBearingMinutes in cumulus.ini), rounded down to nearest 10 degrees
|Annual rainfall total for rainfall season year (i.e. starting month as set on Configuration menu, station screen,  Annual rainfall frame)
|-
|-
|<#BearingRangeTo10>
|<#ConsecutiveRainDays>
|The 'highest' clockwise bearing in the last 10 minutes (or as configured using AvgBearingMinutes in cumulus.ini), rounded down to nearest 10 degrees
|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).
|-
|-
|<#WindRoseData>
|<#ConsecutiveDryDays>
|A comma-separated list of the wind 'totals' used to draw the wind rose (8 or 16 values)
|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
|-
|-
|<#WindRosePoints>
|colspan="2" style="background:lightgray;"|Pressure
|The number of items in <#WindRoseData> (i.e. 8 or 16)
|-
|-
|<#WindSampleCount>
|<#press>
|The number of wind samples making up the wind rose (etc) data (up to 3600)
|The [http://en.wikipedia.org/wiki/Sea_level_pressure sea level pressure]
|-
|-
|colspan="2" style="background:lightgray;"|Miscellaneous
|<#presstrendval>
|The average rate of pressure change over the last three hours.  Trend = (pressure_now - pressure_3hrs_ago) / 3    (Fixed from version 1.7.7 5th March 2008)
|-
|-
|<#cloudbase>
|<#presstrend>
|Calculated [http://en.wikipedia.org/wiki/Cloud_base cloud base]
|The pressure trend in words - values can be set in the 'strings.ini' file
|-
|-
|<#cloudbasevalue>
|<#presstrendenglish>
|Current calculated cloud base without units
| 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). From version 1.8.8 1st December 2009
|-
|-
|<#UV>
| <#PressChangeLast3Hours>
|Current [http://en.wikipedia.org/wiki/Uv_index UV index]. Requires your station to have a UV sensor.
|[[File:Badge vMx.png]] Available from version 3.11.1
 
Total Pressure Change since 3 hours ago
|-
|-
|<#SolarRad>
|<#altimeterpressure>
|Current [http://en.wikipedia.org/wiki/Solar_radiation solar radiation]. Requires your station to have a solar sensor.
|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
|-
|-
|<#Light>
|<#wlatest>
|Current Current light level in Lux. Requires your station to have a solar sensor. Only applies to Fine Offset stations.
|Current wind speed reading from console. Corresponds to 'latest' on the Cumulus main screen.
|-
|-
|[[Forecast_webtag|<#forecast>]]
|<#bearing>
|The current forecast
|Current wind bearing in degrees
|-
|-
|<#forecastenc>
|<#currentwdir>
|The same as <#forecast> but with all reserved HTML characters, and those above character code 159, encoded as HTML entities
|Current wind bearing as a compass point - e.g. ESE
|-
|-
| <#forecastJsEnc>
|<#wspeed>
|[[File:Badge vMx.png]] Available from version 3.11.0
|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.
The current forecast encoded for JavaScript
|-
|-
|<#forecastnumber>
|<#avgbearing>
|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
|Average wind bearing in degrees over last configured interval minutes. Range 1-360, 0=Calm
 
This is calculated by taking the wind direction and speed for the last 10 minutes (or other interval as configured), calculates the sums of the North/South and East/West vector components, divides the E/W component sum by the N/S component sum, and takes the arctan.
|-
|-
|<#cumulusforecast>
|<#wdir>
|Always gives Cumulus (Zambretti) [[Forecast_webtag|forecast]], even if the <#forecast> tag provides a station forecast
|Average wind bearing over last 10 minutes as a [http://en.wikipedia.org/wiki/Compass compass] point - e.g. ESE
|-
|-
|<#cumulusforecastenc>
|<#wgust>
|The same as <#cumulusforecast> but with all reserved HTML characters, and those above character code 159, encoded as HTML entities
|The highest wind reading in the last 10 minutes. Corresponds to 'gust' on the Cumulus main screen.
|-
|<#WindSampleCount>
|The number of wind samples making up the wind rose (etc) data (up to 3600)
|-
|<#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:
* Oregon:  x=12 seconds (see https://cumulus.hosiene.co.uk/viewtopic.php?p=37#p37) so 12 hours worth in full array
* Davis:  x=2 or 3 seconds (see https://cumulus.hosiene.co.uk/viewtopic.php?p=37#p37) so 2.5 hours worth in full array
* Fine Offset: Cumulus 1 reads the wind data every minute (although station transmits wind data every 40 seconds), so 60 hours worth in full array
* Davis WLL: x=2.5 seconds (see https://cumulus.hosiene.co.uk/viewtopic.php?p=160900#p160900) so 2.5 hours worth in full array
 
|-
|-
| <#cumulusforecastJsEnc>
|<#wspddata>
|[[File:Badge vMx.png]] Available from version 3.11.0
|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''' tag. Reading interval x varies by station type (see above).
The current  Cumulus (Zambretti) forecast  encoded for JavaScript
|-
|-
|<#wsforecast>
|<#nextwindindex>
|Always gives station forecast (if available)
|The index of the entries in <#wdirdata> and <#wspddata> that 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!
|-
|-
|<#wsforecastenc>
|<#WindRoseData>
|The same as <#wsforecast> but with all reserved HTML characters, and those above character code 159, encoded as HTML entities
|A comma-separated list of the wind 'totals' used to draw the wind rose (8 or 16 values)
|-
|-
| <#wsforecastJsEnc>
|<#WindRosePoints>
|[[File:Badge vMx.png]] Available from version 3.11.0
|The number of items in <#WindRoseData> (i.e. 8 or 16), as configured on [[Cumulus_Screenshots#Display_and_Colour_screens_as_at_version_1.9.4|display settings screen]]
 
The current  station forecast  encoded for JavaScript
|-
|-
|<#currcond>
|<#beaufort>
|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
|The current wind speed on the [http://en.wikipedia.org/wiki/Beaufort_scale Beaufort scale] (e.g. F8)
|-
|-
|<#currcondenc>
|<#beaufortnumber>
|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.
|The current wind speed on the Beaufort scale, without a leading "F", e.g. "6"
|}
 
===Extra Sensors===
 
Some tags are only available for certain builds, if the tables below do not say which releases they apply to, see general tip at top of page to check for the build you are using. In particular Cumulus 1 has fewer channels available in its earlier versions, and the final legacy software version 1.9.4 offers just 42 of the 62 extra sensor web tags available in MX.
 
The extra sensors functionality in Cumulus only supports processing for current spot values as read from the sensors, the only processing is to convert the units ready for output, so only current conditions can be reported in web tags.  
 
Periodically spot extra sensor values are logged, see the [[Extra_Sensor_Files]] page for information about log files from where you can extract the past spot values.
 
====Extra Sensors: Davis models and Oregon Scientific WMR928, WR100/200 ====
 
These web tags hold current values for additional sensors supported by Cumulus 1 and MX.
 
For Oregon Scientific model like WMR-200 with USB connection, please refer to [[#Web tags mentioning (outside) temperature]] because any of the extra temperature tags below can be redirected to '''<#temp>''', and consequently also have web tags reporting daily extremes and longer period extreme records.
{| class="wikitable" border="1"
|-
|-
!style="width:150px"|Web tag_name
|<#beaudesc>
!style="width:600px"|The related description can be changed in 'strings.ini', but below are default descriptions that will be shown in viewer/editor
|The current wind speed Beaufort description (e.g. "Gale")
|-
|-
|<#ExtraTemp1>
|<#BearingRangeFrom>
|Extra temperature channel 1
|The 'lowest' clockwise bearing in the last 10 minutes (or as configured using AvgBearingMinutes in [[Cumulus.ini (Cumulus 1)|cumulus.ini]])
|-
|-
|<#ExtraTemp2>
|<#BearingRangeTo>
|Extra temperature channel 2
|The 'highest' clockwise bearing in the last 10 minutes (or as configured using AvgBearingMinutes in cumulus.ini)
|-
|-
|<#ExtraTemp3>
|<#BearingRangeFrom10>
|Extra temperature channel 3
|The 'lowest' clockwise bearing in the last 10 minutes (or as configured using AvgBearingMinutes in cumulus.ini), rounded down to nearest 10 degrees
|-
|-
|colspan="2"|... and so on up to <#ExtraTemp10> = Extra temperature channel 10
|<#BearingRangeTo10>
|The 'highest' clockwise bearing in the last 10 minutes (or as configured using AvgBearingMinutes in cumulus.ini), rounded down to nearest 10 degrees
|-
|-
|<#ExtraDP1>
|colspan="2" style="background:lightgray;"|Miscellaneous
|Extra dew point channel 1
|-
|-
|<#ExtraDP2>
|<#cloudbase>
|Extra dew point channel 2
|Calculated [http://en.wikipedia.org/wiki/Cloud_base cloud base]
|-
|-
|<#ExtraDP3>
|<#cloudbasevalue>
|Extra dew point channel 3
|Current calculated cloud base without units
|-
|-
|colspan="2"|... and so on up to <#ExtraDP10>
|<#UV>
|Current [http://en.wikipedia.org/wiki/Uv_index UV index]. Requires your station to have a UV sensor.
|-
|-
|<#ExtraHum1>
|<#SolarRad>
|Extra humidity channel 1
|Current [http://en.wikipedia.org/wiki/Solar_radiation solar radiation]. Requires your station to have a solar sensor.
|-
|-
|<#ExtraHum2>
|Extra humidity channel 2
|-
|-
|<#ExtraHum3>
|<#Light>
|Extra humidity channel 3
|Current Current light level in Lux. Requires your station to have a solar sensor. Only applies to Fine Offset stations.
|-
|-
|colspan="2"|... and so on up to <#ExtraHum10>
|[[Forecast_webtag|<#forecast>]]
|The current forecast
|-
|-
|<#SoilTemp1>
|<#forecastenc>
|Soil temperature 1
|The same as <#forecast> but with all reserved HTML characters, and those above character code 159, encoded as HTML entities
|-
|-
|<#SoilTemp2>
| <#forecastJsEnc>
|Soil temperature 2
|[[File:Badge vMx.png]] Available from version 3.11.0
The current forecast encoded for JavaScript
|-
|-
|colspan="2"|... and so on up to <#SoilTemp16>
|<#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
|-
|-
|<#SoilMoisture1>
|<#cumulusforecast>
|Soil moisture 1
|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
|-
|-
|<#SoilMoisture2>
| <#cumulusforecastJsEnc>
|Soil moisture 2
|[[File:Badge vMx.png]] Available from version 3.11.0
The current  Cumulus (Zambretti) forecast  encoded for JavaScript
|-
|-
|colspan="2"|... and so on up to <#SoilMoisture16>
|<#wsforecast>
|Always gives station forecast (if available)
|-
|-
|<#LeafTemp1>
|<#wsforecastenc>
|Leaf temperature 1
|The same as <#wsforecast> but with all reserved HTML characters, and those above character code 159, encoded as HTML entities
|-
|-
|<#LeafTemp2>
| <#wsforecastJsEnc>
|Leaf temperature 2
|[[File:Badge vMx.png]] Available from version 3.11.0
 
The current  station forecast  encoded for JavaScript
|-
|-
|<#LeafWetness1>
|<#currcond>
|Leaf wetness 1
|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
|-
|-
|<#LeafWetness2>
|<#currcondenc>
|Leaf wetness 2
|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.
|}
|}


====Extra Sensors:  Davis AirLink ====
===Extra Sensors===  
New from version 3.9.0. Not available for earlier MX, not available for Cumulus 1.
 
Some tags are only available for certain builds, if the tables below do not say which releases they apply to, see general tip at top of page to check for the build you are using. In particular Cumulus 1 has fewer channels available in its earlier versions, and the final legacy software version 1.9.4 offers just 42 of the 62 extra sensor web tags available in MX.
 
The extra sensors functionality in Cumulus only supports processing for current spot values as read from the sensors, the only processing is to convert the units ready for output, so only current conditions can be reported in web tags.
 
Periodically spot extra sensor values are logged, see the [[Extra_Sensor_Files]] page for information about log files from where you can extract the past spot values.
 
====Extra Sensors: Davis models and Oregon Scientific WMR928, WR100/200 ====


Note, that you can configure an Indoor or Outdoor (or both) AirLink, most people will use an outdoor. There are a similar set of tags for each device.
These web tags hold current values for additional sensors supported by Cumulus 1 and MX.  


For Oregon Scientific model like WMR-200 with USB connection, please refer to [[#Web tags mentioning (outside) temperature]] because any of the extra temperature tags below can be redirected to '''<#temp>''', and consequently also have web tags reporting daily extremes and longer period extreme records.
{| class="wikitable" border="1"
{| class="wikitable" border="1"
|-
|-
!style="width:150px" |Web tag_name
!style="width:150px"|Web tag_name
!style="width:600px" |Function
!style="width:600px"|The related description can be changed in 'strings.ini', but below are default descriptions that will be shown in viewer/editor
|-
|-
|colspan="2" style="background:lightgray;"|Particulate Matter
|<#ExtraTemp1>
|Extra temperature channel 1
|-
|-
|<#AirLinkPm1[InǀOut]>
|<#ExtraTemp2>
|Current particulate matter of 1 μm, or less count
|Extra temperature channel 2
|-
|-
|<#AirLinkPm2p5[InǀOut]>
|<#ExtraTemp3>
|Currentparticulate matter of 2.5 μm, or less, count
|Extra temperature channel 3
|-
|-
|<#AirLinkPm2p5_1hr[InǀOut]>
|colspan="2"|... and so on up to <#ExtraTemp10> = Extra temperature channel 10
|Last hour average particulate matter of 2.5 μm, or less, count
|-
|-
|<#AirLinkPm2p5_3hr[InǀOut]>
|<#ExtraDP1>
|Last 3 hours average particulate matter of 2.5 μm, or less, count
|Extra dew point channel 1
|-
|-
|<#AirLinkPm2p5_24hr[InǀOut]>
|<#ExtraDP2>
|Last 24 hours average particulate matter of 2.5 μm, or less, count
|Extra dew point channel 2
|-
|-
|<#AirLinkPm2p5_Nowcast[InǀOut]>
|<#ExtraDP3>
|The 24 hour "nowcast" weighted average particulate matter of 2.5 μm, or less, count
|Extra dew point channel 3
|-
|-
|<#AirLinkPm10[InǀOut]>
|colspan="2"|... and so on up to <#ExtraDP10>
|Current particulate matter of 10 μm, or less, count
|-
|-
|<#AirLinkPm10_1hr[InǀOut]>
|<#ExtraHum1>
|Last hour average particulate matter of 10 μm, or less, count
|Extra humidity channel 1
|-
|-
|<#AirLinkPm10_3hr[InǀOut]>
|<#ExtraHum2>
|Last 3 hours average particulate matter of 10 μm, or less, count
|Extra humidity channel 2
|-
|-
|<#AirLinkPm10_24hr[InǀOut]>
|<#ExtraHum3>
|Last 24 hours average particulate matter of 10 μm, or less, count
|Extra humidity channel 3
|-
|-
|<#AirLinkPm10_Nowcast[InǀOut]>
|colspan="2"|... and so on up to <#ExtraHum10>
|The 24 hour "nowcast" weighted average particulate matter of 10 μm, or less, count
|-
|-
|colspan="2" style="background:lightgray;"|Air Quality Index Values
|<#SoilTemp1>
|Soil temperature 1
|-
|-
|<#AirLinkAqiPm2p5[InǀOut]>
|<#SoilTemp2>
|Current particulate matter of 2.5 μm, or less AQI value - allows use of the "dp=n" and "tc=y" parameters
|Soil temperature 2
|-
|-
|<#AirLinkAqiPm2p5_1hr[InǀOut]>
|colspan="2"|... and so on up to <#SoilTemp16>
|Last hour average particulate matter of 2.5 μm, or less, AQI value - allows use of the "dp=n" and "tc=y" parameters
|-
|-
|<#AirLinkAqiPm2p5_3hr[InǀOut]>
|<#SoilMoisture1>
|Last 3 hour average particulate matter of 2.5 μm, or less, AQI value - allows use of the "dp=n" and "tc=y" parameters
|Soil moisture 1
|-
|-
|<#AirLinkAqiPm2p5_24hr[InǀOut]>
|<#SoilMoisture2>
|Last 24 hour average particulate matter of 2.5 μm, or less, AQI value - allows use of the "dp=n" and "tc=y" parameters
|Soil moisture 2
|-
|-
|<#AirLinkAqiPm2p5_Nowcast[InǀOut]>
|colspan="2"|... and so on up to <#SoilMoisture16>
|Last 24 hour "nowcast" weighted average particulate matter of 2.5 μm, or less, AQI value - allows use of the "dp=n" and "tc=y" parameters
|-
|-
|<#AirLinkAqiPm210[InǀOut]>
|<#LeafTemp1>
|Current particulate matter of 10 μm, or less value - allows use of the "dp=n" and "tc=y" parameters
|Leaf temperature 1
|-
|-
|<#AirLinkAqiPm10_1hr[InǀOut]>
|<#LeafTemp2>
|Last hour average particulate matter of 10 μm, or less, AQI value - allows use of the "dp=n" and "tc=y" parameters
|Leaf temperature 2
|-
|-
|<#AirLinkAqiPm10_3hr[InǀOut]>
|<#LeafWetness1>
|Last 3 hour average particulate matter of 10 μm, or less AQI value - allows use of the "dp=n" and "tc=y" parameters
|Leaf wetness 1
|-
|-
|<#AirLinkAqiPm10_24hr[InǀOut]>
|<#LeafWetness2>
|Last 24 hour average particulate matter of 10 μm, or less AQI value - allows use of the "dp=n" and "tc=y" parameters
|Leaf wetness 2
|-
|}
|<#AirLinkAqiPm10_Nowcast[InǀOut]>
 
|Last 24 hour "nowcast" weighted average particulate matter of 10 μm, or less AQI value - allows use of the "dp=n" and "tc=y" parameters
====Extra Sensors:  Davis AirLink ====
New from version 3.9.0. Not available for earlier MX, not available for Cumulus 1.
 
Note, that you can configure an Indoor or Outdoor (or both) AirLink, most people will use an outdoor. There are a similar set of tags for each device.
 
{| class="wikitable" border="1"
|-
|-
|colspan="2" style="background:lightgray;"|Stats Values
!style="width:150px" |Web tag_name
!style="width:600px" |Function
|-
|-
|<#AirLinkPct_1hr[InǀOut]>
|colspan="2" style="background:lightgray;"|Particulate Matter
|Percentage of possible values that were included in the 1 hour averages
|-
|-
|<#AirLinkPct_3hr[InǀOut]>
|<#AirLinkPm1[InǀOut]>
|Percentage of possible values that were included in the 3 hour averages
|Current particulate matter of 1 μm, or less count
|-
|-
|<#AirLinkPct_24hr[InǀOut]>
|<#AirLinkPm2p5[InǀOut]>
|Percentage of possible values that were included in the 24 hour averages
|Currentparticulate matter of 2.5 μm, or less, count
|-
|-
|<#AirLinkPct_1hr[InǀOut]>
|<#AirLinkPm2p5_1hr[InǀOut]>
|Percentage of possible values that were included in the 24 hour weighted averages
|Last hour average particulate matter of 2.5 μm, or less, count
|-
|-
|colspan="2" style="background:lightgray;"|Sensor Info
|<#AirLinkPm2p5_3hr[InǀOut]>
|Last 3 hours average particulate matter of 2.5 μm, or less, count
|-
|-
|<#AirLinkFirmwareVersion[InǀOut]>
|<#AirLinkPm2p5_24hr[InǀOut]>
|Shows the AirLink firmware version as a date string.
|Last 24 hours average particulate matter of 2.5 μm, or less, count
NOTE: This web tag requires a WeatherLink Pro subscription to work
|-
|-
|<#AirLinkTemp[InǀOut]>
|<#AirLinkPm2p5_Nowcast[InǀOut]>
|The sensors internal temperatue value
|The 24 hour "nowcast" weighted average particulate matter of 2.5 μm, or less, count
|-
|-
|<#AirLinkHum[InǀOut]>
|<#AirLinkPm10[InǀOut]>
|The sensors internal humidity value
|Current particulate matter of 10 μm, or less, count
|-
|-
|<#AirLinkWifiRssi[InǀOut]>
|<#AirLinkPm10_1hr[InǀOut]>
|The sensors WiFi signal strength in dB - anything below -90 is considered very poor.
|Last hour average particulate matter of 10 μm, or less, count
NOTE: This web tag requires a WeatherLink Pro subscription to work
|}
 
 
 
====Extra Sensors: Ecowitt====
 
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 as a generic name for stations sold under a variety of branding, in this Wiki.
 
[[File:Badge v1.png]]Not available in Cumulus 1.
 
=====Extra Sensors: Ecowitt WH45 CO₂ sensor=====
 
[[File:Badge vMx.png]] Unless otherwise indicated these web tags become available from release 3.9.5.
 
<big>THE INFORMATION HERE IS TAKEN FROM RELEASE ANNOUNCEMENTS THAT DO NOT EXPLAIN WHAT THESE WEB TAGS REPORT
 
PLEASE WOULD SOMEBODY WHO UNDERSTANDS THIS TERMINOLOGY UPDATE THE FOLLOWING TABLE</big>
 
{| class="wikitable" border="1"
|-
|-
!style="width:150px" |Web tag_name
|<#AirLinkPm10_3hr[InǀOut]>
!style="width:600px" |Function
|Last 3 hours average particulate matter of 10 μm, or less, count
|-
|-
| <#CO2-pm2p5>
|<#AirLinkPm10_24hr[InǀOut]>
| Air Quality expressed in terms of particulate matter of 2.5 micrometres or less
|Last 24 hours average particulate matter of 10 μm, or less, count
|-
|-
| <#CO2-pm2p5-24h>
|<#AirLinkPm10_Nowcast[InǀOut]>
| Air Quality expressed in terms of particulate matter of 2.5 μm, or less, Last 24 hours average
|The 24 hour "nowcast" weighted average particulate matter of 10 μm, or less, count
 
WILL SOMEBODY WHO KNOWS UPDATE THIS ENTRY AND OTHERS
|-
|-
| <#CO2-pm10>
|colspan="2" style="background:lightgray;"|Air Quality Index Values
| Air Quality expressed in terms of particulate matter of 10 μm, or less
|-
|-
| <#CO2-pm10-24h>
|<#AirLinkAqiPm2p5[InǀOut]>
| Air Quality expressed in terms of particulate matter of 10 μm, or less, Last 24 hours average
|Current particulate matter of 2.5 μm, or less AQI value - allows use of the "dp=n" and "tc=y" parameters
 
WILL SOMEBODY WHO KNOWS UPDATE THIS ENTRY AND OTHERS
|-
|-
| <#CO2-temp>
|<#AirLinkAqiPm2p5_1hr[InǀOut]>
| Temperature as reported by Air Quality monitor
|Last hour average particulate matter of 2.5 μm, or less, AQI value - allows use of the "dp=n" and "tc=y" parameters
|-
|-
| <#CO2-hum>
|<#AirLinkAqiPm2p5_3hr[InǀOut]>
| Relative Humidity as reported by Air Quality monitor
|Last 3 hour average particulate matter of 2.5 μm, or less, AQI value - allows use of the "dp=n" and "tc=y" parameters
|}
 
=====Extra Sensors: Ecowitt WH34 soil and water sensor=====
 
Cumulus MX can support the Ecowitt WH34 (other model types exist and are reported here as if WH34) soil and water temperature sensors.
 
They are reported as "User Temperture 1" to "User Temperature 8", as listed in the table within next sub-section.
 
 
=====Extra Sensors: Ecowitt Air quality, leak sensors, lighting detector, and extra temperature sensors=====
 
[[File:Badge v1.png]] Not available in Cumulus 1.
 
[[File:Badge vMx.png]] Please see release announcements for when individual web tags became available
 
This sub-section applies only to those using Ecowitt GW1000 (also Froggit DS1500, and other equivalents, see [[Supported Devices]]) 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"
|-
|-
!style="width:150px" |Web tag_name
|<#AirLinkAqiPm2p5_24hr[InǀOut]>
!style="width:600px" |Function
|Last 24 hour average particulate matter of 2.5 μm, or less, AQI value - allows use of the "dp=n" and "tc=y" parameters
|-
|-
|<#GW1000FirmwareVersion>
|<#AirLinkAqiPm2p5_Nowcast[InǀOut]>
|GW1000 firmware version string
|Last 24 hour "nowcast" weighted average particulate matter of 2.5 μm, or less, AQI value - allows use of the "dp=n" and "tc=y" parameters
|}
 
 
{| class="wikitable" border="1"
|-
|-
!style="width:150px"|Web tag_name
|<#AirLinkAqiPm210[InǀOut]>
!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
|Current particulate matter of 10 μm, or less value - allows use of the "dp=n" and "tc=y" parameters
|-
|-
|<#AirQuality1>
|<#AirLinkAqiPm10_1hr[InǀOut]>
| Air quality index (24 hour) 1
|Last hour average particulate matter of 10 μm, or less, AQI value - allows use of the "dp=n" and "tc=y" parameters
|-
|-
|<#AirQuality2>
|<#AirLinkAqiPm10_3hr[InǀOut]>
| Air quality index (24 hour) 2
|Last 3 hour average particulate matter of 10 μm, or less AQI value - allows use of the "dp=n" and "tc=y" parameters
|-
|-
|colspan="2"|... and so on up to <#AirQuality4>
|<#AirLinkAqiPm10_24hr[InǀOut]>
|Last 24 hour average particulate matter of 10 μm, or less AQI value - allows use of the "dp=n" and "tc=y" parameters
|-
|-
|<#LeakSensor1>
|<#AirLinkAqiPm10_Nowcast[InǀOut]>
|Leak sensor 1 - returns false/true as 0 or 1
|Last 24 hour "nowcast" weighted average particulate matter of 10 μm, or less AQI value - allows use of the "dp=n" and "tc=y" parameters
|-
|-
|<#LeakSensor2>
|colspan="2" style="background:lightgray;"|Stats Values
|Leak sensor 2 - returns false/true as 0 or 1
|-
|-
|colspan="2"|... and so on up to <#LeakSensor4>
|<#AirLinkPct_1hr[InǀOut]>
|Percentage of possible values that were included in the 1 hour averages
|-
|-
|<#LightningDistance>
|<#AirLinkPct_3hr[InǀOut]>
|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 '----')
|Percentage of possible values that were included in the 3 hour averages
|-
|-
|<#LightningTime>
|<#AirLinkPct_24hr[InǀOut]>
|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 '----')
|Percentage of possible values that were included in the 24 hour averages
|-
|<#AirLinkPct_1hr[InǀOut]>
|Percentage of possible values that were included in the 24 hour weighted averages
|-
|colspan="2" style="background:lightgray;"|Sensor Info
|-
|<#AirLinkFirmwareVersion[InǀOut]>
|Shows the AirLink firmware version as a date string.
NOTE: This web tag requires a WeatherLink Pro subscription to work
|-
|-
|<#LightningStrikesToday>
|<#AirLinkTemp[InǀOut]>
|Number of strikes since midnight, default 0
|The sensors internal temperatue value
|-
|-
|<#UserTemp1>  
|<#AirLinkHum[InǀOut]>
|User Temperature 1
|The sensors internal humidity value
|-
|-
|colspan="2"|... and so on up to <#UserTemp8> = User temperature 8
|<#AirLinkWifiRssi[InǀOut]>
|The sensors WiFi signal strength in dB - anything below -90 is considered very poor.
NOTE: This web tag requires a WeatherLink Pro subscription to work
|}
|}


==Recent History==


While Cumulus is left running, from version 1.9.3 (beta build 1033 release 10 April 2012), every minute a set of current spot values is stored.  This '''high resolution data''' is kept for seven days, with the oldest set being discarded each time a new set is added.


There is one tag name listed in the table below for each weather derivative available at the release you are running.  You pick the time in minutes ago using an input modification parameter choosing from those listed at [[Webtags/Parameters#Input Modification Parameters for Recent History]]. You can specify 1 to 10 079 minutes ago, and (to save dealing with large numbers) you can specify this using a combination of input parameters representing integer days, integer hours, and integer minutes.
====Extra Sensors: Ecowitt====


===What happens when I need to stop and restart Cumulus?===
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 as a generic name for stations sold under a variety of branding, in this Wiki.


This depends on the release you are running.  
[[File:Badge v1.png]]Not available in Cumulus 1.


The graph images that Cumulus 1 generates, the data for the detailed charts that MX can plot, and various internal calculations that MX makes, and indeed the recent history web tags themselves, all access data for the recent past.  That data is available at one minute intervals, since you started Cumulus, because of this recent history functionality. But if those charts, or calculations, need to include a period before Cumulus was started, then they might be using archive data obtained from your weather station.
=====Extra Sensors: Ecowitt WH45 CO₂ sensor=====


====MX release 3.12.0 (beta build 3134) onwards====
[[File:Badge vMx.png]] Unless otherwise indicated these web tags become available from release 3.9.5.


The recent history is stored in a SQLite3 database table [[cumulusmx.db#Release 3.12.0 onwards|RecentData]] and therefore if you stop MX, the recent history data up to the time MX stopped has become persistent, and is available when MX starts again. Thus the charts, and internal calculations, mentioned above can make use of recent history data from the previous Cumulus session.
{| class="wikitable" border="1"
 
|-
When you do restart MX, if your weather station can store historic data, then its logger is read during the restart as archive data for the period since MX was last running until the time of restart, and obviously only available at the resolution of that historic data (be it every 10 minutes, or every 30 minutes or whatever).
!style="width:150px" |Web tag_name
 
!style="width:600px" |Function
If MX was stopped for a short period, then on restarting MX, the '''RecentData''' table will be updated by discarding any rows over 7 days old, and for the times during the '''short period''' adding that archive data at whatever station logging interval resolution is available.
|-
| <#CO2>
| The actual CO<small>2</small>concentration in ppm
|-
| <#CO2-pm2p5>
| Air Quality expressed in terms of particulate matter of 2.5 μm/m<small>3</small> or less
|-
| <#CO2-pm2p5-24h>
| Air Quality expressed in terms of particulate matter of 2.5 μm/m<small>3</small>, or less, 24 hours moving average
|-
| <#CO2-pm10>
| Air Quality expressed in terms of particulate matter of 10 μm/m<small>3</small>, or less (yes, this includes the 2.5 figure)
|-
| <#CO2-pm10-24h>
| Air Quality expressed in terms of particulate matter of 10 μm/m<small>3</small>, or less, 24 hours moving average
|-
| <#CO2-temp>
| Temperature as reported by Air Quality monitor.  


If Cumulus MX is offline for a prolonged period, (and when you first run 3.12.0, as the '''RecentData''' table does not yet exist) then all the data for the previous just over 10 thousand minutes will be at this lower station logging interval resolution.
Note that this temperature has nothing to do with the temperature as reported by the main weather station. It reflects the temperature of the sensor and would be used in combination with the sensors measured humidity (see next) for correction of the measured PM (particulate matter) value. Determination of how to correct the PM value is highly dependent on the conditions and placement of the sensor. See the specification sheet for the sensor or create some multivariate regression line based on calibration measurements. This is also valid for PM sensors like the AirLink. The normal amateur usage of PM sensors is that the uncorrected values are published.  
|-
| <#CO2-hum>
| Relative Humidity as reported by Air Quality monitor
|}


====Legacy release 1.9.3 to MX 3.11.4====
=====Extra Sensors: Ecowitt WH34 soil and water sensor=====


The 'recent historical data' is based on an array stored by the Cumulus code.  Therefore, if Cumulus stops, all the high resolution data is lost.
Cumulus MX can support the Ecowitt WH34 (other model types exist and are reported here as if WH34) soil and water temperature sensors.


When you do restart MX, if your weather station can store historic data, then its logger is read during the restart as archive data for the period from 7 days ago until the time of restart, and obviously only available at the station logging interval resolution of that historic data (be it every 10 minutes, or every 30 minutes or whatever).
They are reported as "User Temperture 1" to "User Temperature 8", as listed in the table within next sub-section.


===If the derivative you want is not available in your Cumulus release===


As Cumulus has developed, it has been able to calculate more [[Feels Like|weather derivatives]] and more recent history tag names have become available (sometimes recent history tag names have been added in a later release than the release that started calculated the derivative).
=====Extra Sensors: Ecowitt Air quality, leak sensors, lighting detector, and extra temperature sensors=====


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 v1.png]] Not available in Cumulus 1.


===Warning when Daylight Saving Time starts or ends===
[[File:Badge vMx.png]] Please see release announcements for when individual web tags became available
 
Note that Cumulus uses current time, read from the computer, for recent history records.
 
For version 1.9.3 to release 3.11.4, current time determines which array element is used for storing the set of values. 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 (so all your days, even when clock changes happen, are 24 hours long), 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
* ''when the clocks go forward'', one hour in the array simply does not exist.
 
One assumes the same applies from release 3.12.0, but it depends how MX has been coded, as a SQLite3 database uses row numbers as its primary key, and could technically therefore retain the missing hour.
 
=== Table of Recent History web tags available ===
 
 
[[#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.


This sub-section applies only to those using Ecowitt GW1000 (also Froggit DS1500, and other equivalents, see [[Supported Devices]]) 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"
{| class="wikitable" border="1"
|-
|-
!style="width:150px" | Web tag_name
!style="width:150px" |Web tag_name
!style="width:600px" | Function  
!style="width:600px" |Function
!style="width:600px" | Parameters example
|-
|-
|colspan="3" style="background:lightgray;"|Time-stamp tag
|<#GW1000FirmwareVersion>
|GW1000 firmware version string
|}
 
 
{| class="wikitable" border="1"
|-
|-
|<#RecentTS>
!style="width:150px"|Web tag_name
|Gives the timestamp of the data that will be returned for any other recent history tag that uses same '''d, h, and m''' parameters
!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
|<#RecentTS h=3 m=1 format="HH:nn"> for cumulus 1; <#RecentTS h=3 m=1 format="HH:mm"> for cumulus MX
|-
|-
|colspan="3" style="background:lightgray;"|Temperature & Humidity tags
|<#AirQuality1>
| Air quality in μm/m<small>3</small> or less
|-
|-
|<#RecentOutsideTemp>
|<#AirQuality2>
|Outside Temperature
| Air quality in μm/m<small>3</small> or less
| <#RecentOutsideTemp h=3 m=1>&nbsp;<#tempunit> will display the temperature at the start of the period for which <#temptrend> is calculated
|-
|-
|<#RecentWindChill>
|colspan="2"|... and so on up to <#AirQuality4>
|Wind Chill  (if temperature is below 10°C or 50 °F, then the new Feels Like now available in MX (next item) will report this same value).
| <#RecentWindChill d=48 m=1> reports the wind chill temperature 2 days ago
|-
|-
|<#RecentFeelsLike>
|<#AirQualityAvg1>
| [[File:Badge v1.png]] Not available in Cumulus 1.
| 24 hr running average Air quality in μm/m<small>3</small> or less
 
[[File:Badge vMx.png]] Available from version 3.6.11 (b.3087) onwards.
 
Feels Like Temperature
|<#RecentFeelsLike h=12 m=1> reports the feel like temperature 12 hours ago
|-
|-
|<#RecentHumidex>
|<#AirQualityAvg2>
| [[File:Badge v1.png|File]] Not available in Cumulus 1.
| 24 hr running average Air quality in μm/m<small>3</small> or less
 
[[File:Badge vMx.png]] Available from version 3.7.0 (build 3089) onwards.
 
Canadian Humidity Index (humidex) Dimensionless - no units
|<#RecentHumidex h=3> reports humidex 3 hours ago
|-
|-
|<#RecentDewPoint>
|colspan="2"|... and so on up to <#AirQualityAvg4>
|Dew Point
| <#RecentDewPoint h=25> reports the dew point temperature just over a day ago
|-
|-
|<#RecentHeatIndex>
|<#LeakSensor1>
|Heat Index
|Leak sensor 1 - returns false/true as 0 or 1
| <#RecentHeatIndex m=121> reports the heat index about 2 hours ago
|-
|<#LeakSensor2>
|Leak sensor 2 - returns false/true as 0 or 1
|-
|colspan="2"|... and so on up to <#LeakSensor4>
|-
|-
|<#RecentHumidity>
|<#LightningDistance>
|Relative Humidity
|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 '----')
| d=n (where n runs 0 to 6) days ago; h=n (where n is any number of hours ago); m=n (where n is any number of minutes ago)
|-
|-
|colspan="3" style="background:lightgray;"|Wind
|<#LightningTime>
|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 '----')
|-
|-
|<#RecentWindSpeed>
|<#UserTemp1>  
|Wind Speed
|User Temperature 1
| <#RecentWindSpeed m=10> will display the average wind speed 10 minutes ago
|-
|-
|<#RecentWindGust>
|colspan="2"|... and so on up to <#UserTemp8> = User temperature 8
|Wind Gust
|}
 
==Recent History==
 
Please refer to the [[Recent history]] page for full information about using the tags in the following two tables, as material once on this page has been moved there.
 
===Using input/output modification parameters with recent history tag names===


(reports maximum gust from build 1088 of version 1.9.4)
'''All tag names listed below, require the mandatory input modification parameters specified in this table.'''
| <#RecentWindGust d=1 m=1> will report the wind gust at approximately the same time yesterday
The optional output modification parameters available are as specified in this table, depending on tag name:
{| class="wikitable" border="1"
|-
!style="width:150px" | Tag names
!style="width:200px" | Mandatory Input Modification Parameters
!style="width:200px" | Optional Output Modification Parameters
|-
|-
|<#RecentWindLatest>
| <#RecentTS> (see [[#Table of Recent History tag names available]])
|Wind Latest. Note: Wind 'Speed', 'Gust' and 'Latest' have the usual Cumulus meanings
| Mandatory parameters as table at [[Webtags/Parameters#Input_modification_Parameters]]
| d=n (where n runs 0 to 6) days ago; h=n (where n is any number of hours ago); m=n (where n is any number of minutes ago)
| Optional parameters to modify the time format described in tables starting at [[Webtags/Parameters#Multiple_Output_Format_Modifier_parameters_for_times_and_dates]]
|-
|-
|<#RecentWindDir>
| All other tag names in [[#Available in 1.9.3, 1.9.4, and all MX releases]] and [[#Available in MX only]]
|Wind Direction (instantaneous)
| Mandatory parameters as table at [[Webtags/Parameters#Input_modification_Parameters]]
| <#RecentWindDir m=10> will tell you which direction the wind was blowing from 10 minutes ago
| Whether you can modify the way these values are output depends on release you are using:
* From release 3.10.5: Please see tables at [[Webtags/Parameters#Output_Modification_Parameter_for_changing_any_decimal_comma_into_a_decimal_point]] and [[Webtags/Parameters#Controlling_the_number_of_decimal_places]]
* For legacy Cumulus, and earlier MX releases, no output format modification parameters are available, instead see [[#No_Commas]] section on this page.
|}
 
=== Table of Recent History tag names available ===
 
One tag name is available since 1.9.3 to report the time associated with values you request. 
 
Although as [[Recent history]] page explains, the history is intended to cover every minute in last 7 days, some entries may be at less frequent intervals, and when clocks change some entries will be missing altogether.
{| class="wikitable" border="1"
|-
|-
|<#RecentWindAvgDir>
!style="width:150px" | Web tag_name
|Wind Direction (average)
!style="width:600px" | Function
|<#RecentWindAvgDir d=6> will say what the calculated average wind direction was at this time at the start of the week
!style="width:600px" | Parameters example
|-
|-
|colspan="3" style="background:lightgray;"|Pressure
|colspan="3" style="background:lightgray;"|Time-stamp tag
|-
|-
|<#RecentPressure>
|<#RecentTS>
|Sea-level Pressure
|Gives the timestamp of the data that will be returned for any other recent history tag that uses same '''d, h, and m''' parameters
| <#RecentPressure h=3 m=1> gives the sea level pressure when <#presstrendval> started tracking the pressure
|<#RecentTS h=3 m=1 format="HH:nn"> for cumulus 1; <#RecentTS h=3 m=1 format="HH:mm"> for cumulus MX
|}
 
====Available in 1.9.3, 1.9.4, and all MX releases====
 
{| class="wikitable" border="1"
|-
|-
|colspan="3" style="background:lightgray;"|Rainfall
!style="width:150px" | Tag_name
!style="width:600px" | Function
!style="width:600px" | Input Modification Parameters example
|-
|-
|<#RecentRainToday>
|colspan="3" style="background:lightgray;"|Temperature & Humidity tags
|Daily rain total from last roll-over to specified time
| d=n (where n runs 0 to 6) days ago; h=n (where n is any number of hours ago); m=n (where n is any number of minutes ago)
|-
|-
|colspan="3" style="background:lightgray;"|Solar & UV
|<#RecentOutsideTemp>
|Outside Temperature
| <#RecentOutsideTemp h=3 m=1>&nbsp;<#tempunit> will display the temperature at the start of the period for which <#temptrend> is calculated
|-
|-
|<#RecentSolarRad>
|<#RecentWindChill>
|Solar Radiation
|Wind Chill
| <#RecentWindChill d=48 m=1> reports the wind chill temperature 2 days ago
|-
|<#RecentDewPoint>
|Dew Point
| <#RecentDewPoint h=25> reports the dew point temperature just over a day ago
|-
|<#RecentHeatIndex>
|Heat Index
| <#RecentHeatIndex m=121> reports the heat index about 2 hours ago
|-
|<#RecentHumidity>
|Relative Humidity
| d=n (where n runs 0 to 6) days ago; h=n (where n is any number of hours ago); m=n (where n is any number of minutes ago)
| d=n (where n runs 0 to 6) days ago; h=n (where n is any number of hours ago); m=n (where n is any number of minutes ago)
|-
|-
|<#RecentUV>
|colspan="3" style="background:lightgray;"|Wind <br>(Note: Wind 'Speed', 'Gust' and 'Latest' have the usual Cumulus meanings see [[Wind measurement]])
|UV Index
|-
|<#RecentWindSpeed>
|Wind Speed
| <#RecentWindSpeed m=10> will display the average wind speed 10 minutes ago
|-
|<#RecentWindGust>
|Wind Gust
 
(reports maximum gust from build 1088 of version 1.9.4)
| <#RecentWindGust d=1 m=1> will report the wind gust at approximately the same time yesterday
|-
|<#RecentWindLatest>
|Wind Latest.
| d=n (where n runs 0 to 6) days ago; h=n (where n is any number of hours ago); m=n (where n is any number of minutes ago)
| d=n (where n runs 0 to 6) days ago; h=n (where n is any number of hours ago); m=n (where n is any number of minutes ago)
|}
|-
 
|<#RecentWindDir>
=== Other weather derivatives ===
|Wind Direction (instantaneous)
 
| <#RecentWindDir m=10> will tell you which direction the wind was blowing from 10 minutes ago
Although Humidex, 'Apparent Temperature', 'Feels Like temperature' and others listed in Current Conditions section, are not available at all versions, they can be calculated in a script from recent 'outside temperature', 'wind speed', and 'relative humidity' values (using the same time selection for all). There are other derivatives that can be calculated similarly from a set of simultaneous values. Note that Cumulus 1 and MX do not always use identical formula, and although MX added Feels Like it has changed the formula a few times.
|-
 
|<#RecentWindAvgDir>
The relevant formulae using JavaScript, adjust for other languages, for some of these are shown below:
|Wind Direction (average)
 
|<#RecentWindAvgDir d=6> will say what the calculated average wind direction was at this time at the start of the week
==== Canadian Humidity Index ====
|-
 
|colspan="3" style="background:lightgray;"|Pressure
If you are in USA and use Fahrenheit instead of Celsius, you will need to omit the 5/9 term, but as the index is dimensionless no other conversion is needed. This example is for 3 hours ago, change the input parameters to suit your need.
|-
 
|<#RecentPressure>
Cumulus 1:
|Sea-level Pressure
 
| <#RecentPressure h=3 m=1> gives the sea level pressure when <#presstrendval> started tracking the pressure
H = <#RecentOutsideTemp h=3> + 5/9 * (6.1094 * Math.exp(5417.753 *(1/273.16 - 1/ (273.16 + <#RecentDewPoint h=3> )))-10);
|-
 
|colspan="3" style="background:lightgray;"|Rainfall
Cumulus MX:
|-
|<#RecentRainToday>
|Daily rain total from last roll-over to specified time
| d=n (where n runs 0 to 6) days ago; h=n (where n is any number of hours ago); m=n (where n is any number of minutes ago)
|-
|colspan="3" style="background:lightgray;"|Solar & UV
|-
|<#RecentSolarRad>
|Solar Radiation
| d=n (where n runs 0 to 6) days ago; h=n (where n is any number of hours ago); m=n (where n is any number of minutes ago)
|-
|<#RecentUV>
|UV Index
| d=n (where n runs 0 to 6) days ago; h=n (where n is any number of hours ago); m=n (where n is any number of minutes ago)
|}


svp = 6.112 * Math.exp((17.62 * <#RecentOutsideTemp h=3) / (243.12 + parseFloat(<#RecentOutsideTemp h=3)));
====Available in MX only====
H = (5/9 * (<#RecentHumidity h=3> /100 * svp - 10)) + <#RecentOutsideTemp h=3;


==== Apparent Temperature and Feels Like ====
Please note this section has NOT yet been updated for recent MX releases, it appears from [[cumulusmx.db|RecentData table in cumulusmx.db]] that the list here is not complete for MX.  However, no release announcement has been found listing tag names not shown here (i.e. apparent temperature, indoor temperature and humidity, air quality)
 
{| class="wikitable" border="1"
Note this apparent temperature formula uses Celsius for temperature and '''metres per second''' for wind speed. You will need to do the appropriate conversions from the quoted recent history tags if you use different units.  The Australian Apparent temperature formula is same for Cumulus 1 and MX:
|-
 
!style="width:150px" | tag_name
var actualVaporPress = <#RecentHumidity h=3>/100) * 6.105 * Math.exp(17.27 * <#RecentOutsideTemp h=3>) / (237.7 + parseFloat(<#RecentOutsideTemp h=3>))));
!style="width:150px" | Introduced
var appTempDegC = parseFloat(<#RecentOutsideTemp h=3) + (0.33 * actualVaporPress) - (0.7 * <#RecentWindSpeed h=3>) - 4;
!style="width:600px" | Function
 
!style="width:600px" | Input Modification Parameters example
Feels Like was implemented as a recent history web tag at version 3.6.11 (see [[#Feels_Like|Feels Like section below Current condition web tags]]) for the gradual introduction of feels like elsewhere. For earlier MX versions, and if you are using Cumulus 1, you can calculate it:
|-
 
|colspan="4" style="background:lightgray;"|Indoor Temperature & Humidity tags
The formulas below use Celsius for temperature and '''km per hour''' for wind speed. Again, you will need to do the appropriate conversions from the quoted recent history tags if you use different units.
|-
 
|colspan="4" | (to do)
Calculation from recent history tags is much more complicated because there are 3 different calculations: Feels Like reports exactly same as wind chill for temperatures '''below''' 10°C or 50°F so the WC here should equal <#RecentWindChill h=3>:
|-
<pre>if(<#RecentWindSpeed h=3> < 4.828) WC =  <#RecentOutsideTemp h=3>;
|colspan="4" style="background:lightgray;"|Outdoor Temperature & Humidity tags
else{
|-
wind_pow =  Math.pow(<#RecentWindSpeed h=3>, 0.16);
|<#RecentWindChill>
WC = (13.12 + 0.1625 * <#RecentOutsideTemp h=3>) - (11.37 * wind_pow) + (0.3965 * <#RecentOutsideTemp h=3> * wind_pow);// Brackets used to ensure "+" is interpreted as addition not concatenation
| Legacy Cumulus version 1.8.5
} </pre>
|Wind Chill  (if temperature is below 10°C or 50 °F, then the new Feels Like now available in MX (next item) will report this same value).
 
| <#RecentWindChill d=48 m=1> reports the wind chill temperature 2 days ago
For temperatures '''above''' 20°C or 68°F Feels Like uses a different way to calculate apparent temperature that it uses at these higher temperatures (this formula only used for 3.6.10 onwards):
|-
<pre>var actualVaporPress = <#RecentHumidity h=3>/100) * 6.112* Math.exp((17.62 * <#RecentOutsideTemp h=3>)/(243.12 + <#RecentOutsideTemp h=3>)) / 10.0;  // Not same as at build 3084
|<#RecentFeelsLike>
/* uses kilometres per hour for wind speed */
| Available from version 3.6.11 (build 3087) onwards.
/*  What Cumulus MX will use to calculate apparent temperature for feels like is changed very slightly */
| Feels Like Temperature
if(<#RecentWindSpeed h=3> > 72) <#RecentWindSpeed h=3> =72;
| <#RecentFeelsLike h=12 m=1> reports the feel like temperature 12 hours ago
AT= (1.04 * <#RecentOutsideTemp h=3>) + (2 * actualVaporPress) - (0.1805553 * <#RecentWindSpeed h=3>) - 2.7;</pre>
|-
 
|<#RecentHumidex>
For in-between temperatures it uses a more complicated merge of the two formulas for AT and WC as defined above:
| Available from version 3.7.0 (build 3089) onwards.
<pre>app_temp_mult = (<#RecentOutsideTemp h=3> - 10) / 10;
| Canadian Humidity Index (humidex) Dimensionless - no units
wind_chill_mult = 1 - app_temp_mult;
| <#RecentHumidex h=3> reports humidex 3 hours ago
 
|-
FL= AT * app_temp_mult + WC * wind_chill_mult;</pre>
|colspan="4" style="background:lightgray;"|Air Quality tags
|}


== System ==
== System ==
Line 1,480: Line 1,491:
[[File:Badge vMx.png]] Input is to 2 decimal places. Available from version 3.1.1 - build 3054 when weather diary editor was added to MX.  MX allows output in centimetres with decimal places without any script. You can't change the units shown in admin interface, but your value can be input as inches to 2 decimal places if you ignore "cm" that is displayed in that interface.
[[File:Badge vMx.png]] Input is to 2 decimal places. Available from version 3.1.1 - build 3054 when weather diary editor was added to MX.  MX allows output in centimetres with decimal places without any script. You can't change the units shown in admin interface, but your value can be input as inches to 2 decimal places if you ignore "cm" that is displayed in that interface.


[[File:Badge v1.png|Fil]] Input and output is always as integer. Available from very early builds, weather diary input amended from version 1.8.6 14th April 2009 to allow units to be specified on diary edit screen. If you choose to enter as whole millimetres,  you can use JavaScript (or another script language) on your web page to divide the web tag by 10 and get centimetres to 1 decimal place on output.  
[[File:Badge v1.png]] Input and output is always as integer. Available from very early builds, weather diary input amended from version 1.8.6 14th April 2009 to allow units to be specified on diary edit screen. If you choose to enter as whole millimetres,  you can use JavaScript (or another script language) on your web page to divide the web tag by 10 and get centimetres to 1 decimal place on output.  
|-
|colspan="2" style="background:pink;"|MX only
|-
|-
|<#snowlying>
|<#snowlying>
Line 1,535: Line 1,548:
|Today's low apparent temperature
|Today's low apparent temperature
|<#TapptempTL>
|<#TapptempTL>
|-
|colspan="3" style="background:pink;"|MX only
|-
|-
|<#feelslikeTH>
|<#feelslikeTH>
Line 1,557: Line 1,572:
Please see sub-section below current conditions if you are using Cumulus 1 or an earlier version of MX.
Please see sub-section below current conditions if you are using Cumulus 1 or an earlier version of MX.
|<#ThumidexTH>
|<#ThumidexTH>
|-
|colspan="3" style="background:pink;"|Both legacy and MX
|-
|-
|<#heatindexTH>
|<#heatindexTH>
Line 1,674: Line 1,691:
|-
|-
|<#SunshineHours>
|<#SunshineHours>
|Today's hours of sunshine so far. Added in Cumulus 2, then to 1.9.1 build 957, also in MX. From version 3.7.0 takes a parameter "dp=n" so the number of decimal places required can be specified
|Today's hours of sunshine so far. Added in Cumulus 2, then to 1.9.1 build 957, also available in MX. From version 3.7.0 takes a parameter "dp=n" so the number of decimal places required can be specified
|n/a
|n/a
|-
|colspan="3" style="background:pink;"|MX only
|-
|<#LightningStrikesToday>
|Number of strikes since midnight, default 0  - Added at 3.2.0 - b3056, but see subsequent release announcements as the handling of lightning was improved gradually over several subsequent releases.
(other lightning tags can be found in [[#Current_Conditions|Current Conditions table]])
|-
| <#chillhoursToday>
| The incremental chill hours figure since start of today (tag name available from version 3.12.0 beta build 3134, but the coding to process this web tag has a bug at time of adding this note to this Wiki page, as it may incorrectly report 99.99; hopefully a calculation using <#Ychillhours> and <#chillhours> will work better)
(Compare with Cumulative seasonal Chill Hours at end of today <#chillhours> found in [[#Current_Conditions|Current Conditions table]])
|}
|}


== No Commas ==
== No Commas ==


Note that Cumulus does not use thousand separators, so the only places a comma can be used are as a field separator or as a decimal separator. Obviously it cannot be used for both. This section is for those locales where a comma is used instead of a full stop to separate the integer and decimal parts of a number. Some computer languages like JavaScript will not accept a comma being used for this purpose, and Cumulus uses JavaScript for various tasks, as do various third party web pages. From '''version 1.9.3''' build 1045, Cumulus 1 (and MX) has provided some current conditions web tags, some today web tags, and some recent history web tags in an alternative format where (regardless of locale) the number is always output in a format that uses a decimal point. They all correspond to the same tag with 'RC' removed.
'''This section is for those locales where a comma is used instead of a full stop to separate the integer and decimal parts of a number.''' ''This section on this Wiki page was written for the legacy Cumulus (1.9.4) software.'' Although tag names in this section can be used in Cumulus MX, for backwards compatibility, there is now a better way to ensure that the value output by web tags can be understood by script languages which expect a full stop between the integer and decimal parts of a number.


===CURRENT CONDITIONS:===
Note that Cumulus does not use thousand separators, so the only places a comma can be used are as a field separator, or as a decimal separator. Obviously it cannot be used for both.  Some computer languages like JavaScript will not accept a comma being used for this purpose.


<#RCtemp>, <#RCdew>, <#RCheatindex>, <#RChum>, <#RCinhum>, <#RCintemp>, <#RCpress>, <#RCrfall>, <#RCrrate>, <#RCwchill>, <#RCwgust>, <#RCwspeed>, <#RCwlatest>
===MX===


===TODAY:===
Cumulus MX uses JavaScript Object Notation files for many of its data transfers.


<#RCpressTH>,  <#RCpressTL>,  <#RCrrateTM>, <#RCtempTH>, <#RCtempTL>, <#RCwgustTM>,  <#RCdewpointTH>, <#RCdewpointTL>, <#RCwchillTL>, <#RCheatindexTH>, <#RCapptempTH>, <#RCapptempTL>
From '''release 3.5.4''' build 3075, most web tags (one notable exception is indoor temperature <#intemp> where rc parameter not available until release 3.6.8 build 3084), that produce decimal number output now support the "'''rc=y'''" option. e.g. <tt><#tempYH rc=y></tt> will report yesterday's highest temperature using a full stop to separate decimal part where the locale would normally use a comma.


===RECENT HISTORY:===
===Legacy Cumulus===


<#RCRecentOutsideTemp>, <#RCRecentWindSpeed>, <#RCRecentWindGust>, <#RCRecentWindLatest>, <#RCRecentWindChill>, <#RCRecentDewPoint>, <#RCRecentHeatIndex>, <#RCRecentPressure>, <#RCRecentRainToday>, <#RCRecentUV>
Cumulus 1.9.4 uses JavaScript for various tasks, as do various third party web pages.
 
From '''version 1.9.3''' build 1045, Cumulus 1 (and MX) has provided some current conditions web tags, some today web tags, and some recent history web tags in an alternative format where (regardless of locale) the number is always output in a format that uses a decimal point. They are listed in the sub-sections that follow and all correspond to the same tag  name with the letters 'RC' removed that has been listed in respective sections of this Wiki page.
 
====RC CURRENT CONDITIONS:====
 
<#RCtemp>, <#RCdew>, <#RCheatindex>, <#RChum>, <#RCinhum>, <#RCintemp>, <#RCpress>, <#RCrfall>, <#RCrrate>, <#RCwchill>, <#RCwgust>, <#RCwspeed>, <#RCwlatest>
 
====RC TODAY:====
 
<#RCpressTH>,  <#RCpressTL>,  <#RCrrateTM>,  <#RCtempTH>, <#RCtempTL>, <#RCwgustTM>,  <#RCdewpointTH>, <#RCdewpointTL>, <#RCwchillTL>, <#RCheatindexTH>, <#RCapptempTH>, <#RCapptempTL>
 
====RC RECENT HISTORY:====
 
<#RCRecentOutsideTemp>, <#RCRecentWindSpeed>, <#RCRecentWindGust>, <#RCRecentWindLatest>, <#RCRecentWindChill>, <#RCRecentDewPoint>, <#RCRecentHeatIndex>, <#RCRecentPressure>, <#RCRecentRainToday>, <#RCRecentUV>


Although 'Apparent Temperature' is not included as a tag, it can be [[FAQ#What_formula_does_Cumulus_use_for_Apparent_Temperature.3F | calculated]] in a script from the RC tags for 'outside temperature', 'wind speed', and 'relative humidity' values. In php language this is <tt>$RCapptempCALC =  round(<#temp> + (0.33 * (<#hum> / 100 * 6.105 * exp (17.27 * <#temp> / (237.7 + <#temp>) ))) - (0.7 * $wspeed) - 4.0, 2);</tt>.
Although 'Apparent Temperature' is not included as a tag, it can be [[FAQ#What_formula_does_Cumulus_use_for_Apparent_Temperature.3F | calculated]] in a script from the RC tags for 'outside temperature', 'wind speed', and 'relative humidity' values. In php language this is <tt>$RCapptempCALC =  round(<#temp> + (0.33 * (<#hum> / 100 * 6.105 * exp (17.27 * <#temp> / (237.7 + <#temp>) ))) - (0.7 * $wspeed) - 4.0, 2);</tt>.


There are other derivatives that can be calculated similarly from a set of simultaneous values, as described below the recent history section.
There are other derivatives that can be calculated similarly from a set of simultaneous values, as described below the recent history section.
From '''version 3.5.4''' build 3075, most web tags (one notable exception is indoor temperature <#intemp> where rc parameter not available until version 3.6.8 build 3084), that produce decimal number output now support the "'''rc=y'''" option. e.g. <tt><#tempYH rc=y></tt> will report yesterday's highest temperature using a full stop to separate decimal part where the locale would normally use a comma.


==Yesterday==
==Yesterday==
Line 1,715: Line 1,755:
!style="width:550px" | Function
!style="width:550px" | Function
!style="width:150px" | Time
!style="width:150px" | Time
|-
|colspan="3" style="background:pink;"|Legacy and MX
|-
|-
|colspan="3" style="background:lightgray;"|Temperature & Humidity
|colspan="3" style="background:lightgray;"|Temperature & Humidity
Line 1,733: Line 1,775:
|The temperature range (max - min) yesterday
|The temperature range (max - min) yesterday
|n/a
|n/a
|-
| <#Ychillhours>
| [[File:Badge vMx.png]] (Available from release 3.12.0 onwards)
The Cumulative [[Heat/cold_degree_days_and_Chill_hours#Chill_Hours_and.2For_Air_Frost|Chill Hours]] as recorded at rollover (the end of meteorological yesterday)
| n/a
|-
|-
|<#apptempYH>
|<#apptempYH>
Line 1,747: Line 1,783:
|Yesterday's low apparent temperature
|Yesterday's low apparent temperature
|<#TapptempYL>
|<#TapptempYL>
|-
|colspan="3" style="background:pink;"|MX only
|-
| <#Ychillhours>
| The Cumulative [[Heat/cold_degree_days_and_Chill_hours#Chill_Hours_and.2For_Air_Frost|Chill Hours]] as recorded at rollover (the end of meteorological yesterday) (Available from release 3.12.0 onwards)
| n/a
|-
| <#chillhoursYest>
| The incremental [[Heat/cold_degree_days_and_Chill_hours#Chill_Hours_and.2For_Air_Frost|Chill Hours]] change yesterday (Available from release 3.12.0 onwards)
(compare with <#chillhoursToday> described in [[#Today.ini]] table)
| n/a
|-
|-
|<#feelslikeYH>
|<#feelslikeYH>
|[[File:Badge vMx.png]] Available from version 3.6.10   (NOT AVAILABLE IN CUMULUS 1)
|[[File:Badge vMx.png]] Available from version 3.6.10  


Yesterday's high feels like temperature
Yesterday's high feels like temperature
Line 1,755: Line 1,803:
|-
|-
|<#feelslikeYL>
|<#feelslikeYL>
|[[File:Badge vMx.png]] Available from version 3.6.10   (NOT AVAILABLE IN CUMULUS 1)
|Available from version 3.6.10


Yesterday's low feels like temperature
Yesterday's low feels like temperature
Line 1,761: Line 1,809:
|-
|-
|<#humidexYH
|<#humidexYH
|[[File:Badge vMx.png]] Available from version 3.7.0     (NOT AVAILABLE IN CUMULUS 1)
|Available from version 3.7.0


Yesterday's low Canadian Humidity Index
Yesterday's high Canadian Humidity Index
|<#ThumidexYH>
|<#ThumidexYH>
|-
|colspan="3" style="background:pink;"|Legacy and MX
|-
|-
|<#heatindexYH>
|<#heatindexYH>
Line 1,855: Line 1,905:
|The total wind run for yesterday
|The total wind run for yesterday
|n/a
|n/a
|-
|colspan="3" style="background:pink;"|MX only
|-
|-
| <#windAvgY>
| <#windAvgY>
Line 1,861: Line 1,913:
The wind run yesterday divided by 24 hours to express it as an average wind speed
The wind run yesterday divided by 24 hours to express it as an average wind speed
| n/a
| n/a
|-
|colspan="3" style="background:pink;"|Legacy and MX
|-
|-
|colspan="3" style="background:lightgray;"|Miscellaneous
|colspan="3" style="background:lightgray;"|Miscellaneous
Line 2,538: Line 2,592:
|-
|-
|<#sunrise>
|<#sunrise>
|Last sunrise time at the station - This sunrise time is calculated by a third party library each midnight UTC, and each hour Cumulus converts it to local time to ensure shown correctly before and after any clock change.
|Last sunrise time at the station - This sunrise time is calculated by a third party library each midnight UTC (in legacy cumulus), and each hour Cumulus converts it to local time to ensure shown correctly before and after any clock change.
|-
|-
|<#sunset>
|<#sunset>
|Next sunset time at the station - The sunset/sunrise times are calculated each midnight UTC, and each hour Cumulus converts them to local time to ensure it shows them correctly before and after any clock change.
|Next sunset time at the station - The sunset/sunrise times are calculated each midnight UTC (in legacy cumulus), and each hour Cumulus converts them to local time to ensure it shows them correctly before and after any clock change.
|-
|-
|<#daylength>
|<#daylength>
|Length of day in hours and minutes (sunrise to sunset) -  The third party library that Cumulus uses each midnight UTC, may take last sunrise from previous day and next sunset from next day, so the calculation may be off by a minute or so compared to true figure for current day.
|Length of day in hours and minutes (sunrise to sunset) -  The third party library that Cumulus uses each midnight UTC (in legacy cumulus), may take last sunrise from previous day and next sunset from next day, so the calculation may be off by a minute or so compared to true figure for current day.
|-
|-
|<#IsSunUp>
|<#IsSunUp>
Line 2,600: Line 2,654:
|-
|-
|<#SunshineHours>
|<#SunshineHours>
| see[[#Today.ini]] Miscellaneous
| see [[#Today.ini]] Miscellaneous
|-
|-
|<#SunshineHoursY>
|<#SunshineHoursY>
Line 2,854: Line 2,908:
|<#DavisTotalPacketsReceived>
|<#DavisTotalPacketsReceived>
|1.9.2 onwards and MX
|1.9.2 onwards and MX
|Total number of data packets received.
|Total number of data packets received. This stat is not supplied by the Davis WLL station.
|-
|-
|<#DavisTotalPacketsMissed>
|<#DavisTotalPacketsMissed>
|1.9.2 onwards and MX
|1.9.2 onwards and MX
|Number of missed data packets. From version 3.6.0 build 3076, optionally add "tx=n" parameter, where n=1-8 and equals the desired transmitter id.
|Number of missed data packets. From version 3.6.0 build 3076, optionally add "tx=n" parameter, where n=1-8 and equals the desired transmitter id. The default is n=0 and will return the VP2 stats.
|-
|-
|<#DavisMaxInARow>
|<#DavisMaxInARow>
|1.9.2 onwards and MX
|1.9.2 onwards and MX
|Longest streak of consecutive packets received. From version 3.6.0 build 3076, optionally add "tx=n" parameter, where n=1-8 and equals the desired transmitter id.
|Longest streak of consecutive packets received. From version 3.6.0 build 3076, optionally add "tx=n" parameter, where n=1-8 and equals the desired transmitter id. The default is n=0 and will return the VP2 stats.
|-
|-
|<#DavisNumCRCerrors>
|<#DavisNumCRCerrors>
|1.9.2 onwards and MX
|1.9.2 onwards and MX
|Number of packets received with CRC errors. From version 3.6.0 build 3076, optionally add "tx=n" parameter, where n=1-8 and equals the desired transmitter id.
|Number of packets received with CRC errors. From version 3.6.0 build 3076, optionally add "tx=n" parameter, where n=1-8 and equals the desired transmitter id. The default is n=0 and will return the VP2 stats.
|-
|-
|<#DavisNumberOfResynchs>
|<#DavisNumberOfResynchs>
|1.9.2 onwards and MX
|1.9.2 onwards and MX
|Number of times the console resynchronised with the transmitter
|Number of times the console resynchronised with the transmitter. From version 3.6.0 build 3076, optionally add "tx=n" parameter, where n=1-8 and equals the desired transmitter id. The default is n=0 and will return the VP2 stats
|-
|-
|<#DavisFirmwareVersion>
|<#DavisFirmwareVersion>
|1.9.2 onwards and MX
|1.9.2 onwards and MX
|The console firmware version
|The console/WLL firmware version
|-
|-
|<#THWindex>
|<#THWindex>
|1.9.x
|1.9.x
|A derived temperature using Temperature/Humidity/Wind values read from Davis DLL in Cumulus 1.9.x.
|A derived temperature using Temperature/Humidity/Wind values read from Davis DLL in Cumulus 1.9.x.
*The THW Index uses humidity and temperature (like Heat Index), but includes the cooling effects of wind (like wind chill).
*The THW Index uses humidity and temperature (like Heat Index), but includes the cooling effects of wind (like wind chill).
*Available from 1.9.2 Build 1009 (Aug 2011).
*Available from 1.9.2 Build 1009 (Aug 2011).
|-
|-
|<#THSWindex>
|<#THSWindex>
|(1.9.x and) MX
|(1.9.x and) MX
|A heat stress indicator using Temperature/Humidity/Solar/Wind values.
|A heat stress indicator using Temperature/Humidity/Solar/Wind values.
*The THSW Index uses humidity and temperature (like the Heat Index), but also includes the heating effects of sunshine, and the cooling effects of wind.
*The THSW Index uses humidity and temperature (like the Heat Index), but also includes the heating effects of sunshine, and the cooling effects of wind.
*Therefore requires Davis station with solar sensor.
*Therefore requires Davis station with solar sensor.
[http://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=1223&context=animalscinbcr  Approx calculation]: Decrease heat index by 1 unit for each 1 mph increase in wind speed, and for each, either 3 Langley increase in solar radiation, or 10% increase in cloud cover.
[http://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=1223&context=animalscinbcr  Approx calculation]: Decrease heat index by 1 unit for each 1 mph increase in wind speed, and for each, either 3 Langley increase in solar radiation, or 10% increase in cloud cover.
 
'''IMPORTANT NOTES:'''
#Although this tag is available in Cumulus 1.9.x, there is an issue somewhere in the Davis code that prevents Cumulus 1 obtaining the value (so tag always displays zero).
#Search the forum for several discussions about "THSW".
#Cumulus MX reads "LOOP2" packets, and the correct value for this tag can be read there and displayed on 'Now' template.
|-
|<#battery>
|1.x.x and MX
|The console battery condition in volts. eg "4.82v"
|-
|<#txbattery>
<#txbattery channel=1>
|1.8.9 onwards and MX
|The transmitter battery condition, by default it returns the status of all transmitters. (This was displayed from version 1.9.4 to 1.8.9 on the main screen).
'''Cumulus 1.9.3 onwards Only:''' The optional 'channel' parameter returns the status for a particular transmitter, up to channel=8. The channel result is just the string "ok" or "LOW" for a low battery
|-
|<#StormRain>
|1.x.x and MX
|The console 'storm rain' current amount (build 1090 onwards for Cumulus 1; 3021 onwards for MX)
|-
|<#StormRainStart>
|1.x.x and MX
|The console reported '''date''' of the start of the 'storm', you can use [[Webtags/Parameters#Which_tag_names_take_date.2Ftime_output_formatting_modifiers|date output format modifiers]]


'''IMPORTANT NOTES:'''
(Note that the console does not report start time, so the web tag cannot report time.  It appears a minimum of 2 tips within 3 hours will trigger a storm start, so using <#LastRainTip> in a MX script might help)
#Although this tag is available in Cumulus 1.9.x, there is an issue somewhere in the Davis code that prevents Cumulus 1 obtaining the value (so tag always displays zero).
#Search the forum for several discussions about "THSW".
#Cumulus MX reads "LOOP2" packets, and the correct value for this tag can be read there and displayed on 'Now' template.
|-
|<#battery>
|1.x.x and MX
|The console battery condition in volts. eg "4.82v"
|-
|<#txbattery>
<#txbattery channel=1>
|1.8.9 onwards and MX
|The transmitter battery condition, by default it returns the status of all transmitters. (This was displayed from version 1.9.4 to 1.8.9 on the main screen).
'''Cumulus 1.9.3 onwards Only:''' The optional 'channel' parameter returns the status for a particular transmitter, up to channel=8. The channel result is just the string "ok" or "LOW" for a low battery
|-
|<#StormRain>
|1.x.x and MX
|The console 'storm rain' current amount (build 1090 onwards for Cumulus 1; 3021 onwards for MX)
|-
|<#StormRainStart>
|1.x.x and MX
|The console reported '''date''' of the start of the 'storm' (the console does not report start time, but it appears a minimum of 2 tips within 3 hours will trigger a storm start, so using <#LastRainTipISO> in a script might help), but standard Cumulus [[Webtags#Time.2FDate_.27format.27_Parameter| date/time formatting]] can be applied to that date.
|}
|}


Sfws
5,838

edits

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

Navigation menu