Webtags (preserving history): Difference between revisions

[[Category:Terminology]]

<div style="background: LemonChiffon;padding:5px; margin:2px;">

</div>

==General Format for Web Tags==

====General Tip====

<code>ListWebTags=1</code>

<code> ListWebTags=0</code>

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

'''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:

== Why does MX talk about tokens? ==

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

==Scary statistics==

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.

==Still got questions?==

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.

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

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.

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.

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.

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.

Suppose you want to get the values for the following three web tags:

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.

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

Here follow tables indicating what web tag names are available to be used, tables group them by the basic purpose of the tags listed.

==Current Conditions==

FL= AT * app_temp_mult + WC * wind_chill_mult;</pre>

==Today==

This first table lists all the web tags available for reporting what is recorded in the weather diary. Just to be clear, the web tags shown below, will report data for previous day if the current time is before the snow depth hour setting, and report data for the current day if the current time matches the snow depth hour or is later.

===Today.ini===

For web tags that report values that refer to a particular time of day, there is a corresponding web tag that can give the time of day, shown in same row of table below. For those that cover whole day so far, the final column contains "n/a".

{| class="wikitable" border="1"

|-