Webtags (preserving history): Difference between revisions

From Cumulus Wiki
Jump to navigationJump to search

Webtags (preserving history) (view source)

Revision as of 08:19, 8 September 2020

18,694 bytes added ,  08:19, 8 September 2020
m
→‎What this article covers
(41 intermediate revisions by 2 users not shown)
Line 29: Line 29:
=What this article covers =
=What this article covers =


At the last count, a 3.5.x version of MX produces nine and a half million '''web tags'''! But the file mentioned in previous section contains just 717 items (later versions of MX raise this count by another forty tags or so). How come this discrepancy?
#At the last count, a 3.5.x version of MX produces ''nine and a half million'' '''web tags'''!
# Those millions of web tags can actually produce billions of different outputs!
#But the file mentioned in previous section contains just 717 items (at 3.5.0, later versions of MX raise this count by another forty tags or so).  
#How come this discrepancy?


Well each web tag has the general format <tt><#tag_name optional_input_parameter optional_output_parameter></tt> and it is adding these optional parameters that allow 717 tag names to define 9½ million values!
*Well each web tag has the general format <tt><#tag_name optional_input_parameter optional_output_parameter></tt> and it is adding the optional input parameters that allow 717 tag names to define 9½ million values!
*Adding all possible different output parameters generates the billions of different outputs!


Consequently, this article describes:
Consequently, this article describes:
*Over 7 hundred web tags
*Over 7 hundred web tags -'''THIS ARTICLE MAY NOT CONTAIN ALL WEB TAGS AVAILABLE IN LATEST VERSION - It depends on someone updating this article if the developer does not have time to do so'''
*A score of input parameters that modify some of those tags
*A score of input parameters that modify some of those tags (meaning some web tags can represent 12 different months for example)
*The components that make up output parameters that modify almost all web tags that report a time and/or date
*The components that make up output parameters (a guide to how you modify the output format)
*The way that some of those date modifiers are used for naming NOAA reports
** some control number of decimal places
** one controls whether decimal comma (if used) is replaced by decimal point (useful for some script languages)
**the majority modify the output from almost all web tags that report a time and/or date (there are so many ways to represent times and dates this multiples up the available output considerably)
*The way that some of those date modifiers are used for naming NOAA reports (a simple, but useful table)




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


==Applicability by version and build==
==Applicability by version and build==


The tip at the start of this article tells you how to check which tags are available in whatever build of Cumulus you are actually using. Given how often a new release alters either what web tags are available or what parameters can be used with particular web tags, it is not possible for the tables below to tell you precisely how you use web tags at any version.
The tip at the start of this article tells you how to check which tags are available in whatever build of Cumulus you are actually using. Given how often a new release alters either what web tags are available or what parameters can be used with particular web tags, it is possible the tables below do not list all web tags at any version, and the tables can't say which modifiers are available at your version.


Because Cumulus 2 is no longer available, it has been ignored in the tables below.  
Because Cumulus 2 is no longer available, it has been ignored in the tables below.  It never really worked for web page generation, so if you happen to have installed Cumulus 2 from when it was available, you probably don't care which web tags it supports.


[[File:Badge v1.png]]This badge is used to highlight text that applies to Cumulus 1.  
[[File:Badge v1.png]]This badge is used to highlight text that applies to Cumulus 1.  
Line 184: Line 191:
|}
|}


If you migrate from Cumulus 1 (where case does not matter) to Cumulus MX (where case does matter), from version 3.3.0 onwards the NOAA default monthly name if it reads "NOAAMO'mmyy'.txt" (MX believes "mm" '''means minutes''', not month) is changed into "NOAAMO'MMyy'.txt (which works on both Cumulus 1 and MX).
If you migrate from Cumulus 1 (where case does not matter) to Cumulus MX (where case does matter), from version 3.3.0 onwards the NOAA default monthly name if it reads "NOAAMO'mmyy'.txt" (MX believes "mm" '''means minutes''', not month) is changed into "NOAAMO'MMyy'.txt" (which works on both Cumulus 1 and MX).


= Template Files =
= Template Files =
Line 252: Line 259:
===Inconsistency in use of "T"===
===Inconsistency in use of "T"===


*Some web tags for '''today''' include a "T" as a suffix, some do not.  
*The newer web tags for '''today''' include a "T" as a suffix, the older ones do not.
*"T" is used in combination with the web tag name for a value, so a similar name is used for the time-stamp tags
**The lack of a "T" in some today tags causes some confusion with all-time record tags as they have a similar naming structure to these older today web tags.
**This is particularly confusing and is why you must look up today, and all-time, tags in the tables in this article.
*The time-stamp tags add a "T" to the corresponding web tag for the value, but in an inconsistent way:
**the T is a prefix sometimes and  
**the T is a prefix sometimes and  
**the T is a suffix sometimes  
**the T is a suffix sometimes  
*This is particularly confusing and is why you must look up time-stamp tags in the tables in this article.
**This is particularly confusing and is why you must look up time-stamp tags in the tables in this article.


===Choosing script variable names derived from tag names===
===Choosing script variable names derived from tag names===
Line 357: Line 366:
*If Cumulus MX is running on Linux or Mac OS X, or any other device that uses UNIX derived operating system, then it uses '''Mono''' software for same purposes. (MONO is a operating system independent version of .NET, although they are developed independently, they have common origins). Please see the [[Cumulus MX]] article for more details of their differences and what will change in November 2020.
*If Cumulus MX is running on Linux or Mac OS X, or any other device that uses UNIX derived operating system, then it uses '''Mono''' software for same purposes. (MONO is a operating system independent version of .NET, although they are developed independently, they have common origins). Please see the [[Cumulus MX]] article for more details of their differences and what will change in November 2020.
*The date and time format characters in Mono (and .NET) software framework are not exactly the same as the '''Delphi''' software framework ones that Cumulus 1 uses.   
*The date and time format characters in Mono (and .NET) software framework are not exactly the same as the '''Delphi''' software framework ones that Cumulus 1 uses.   
*For Cumulus MX see [http://msdn.microsoft.com/en-us/library/8kb3ddd4(v=vs.110).aspx this Microsoft site] for format selectors available.
*For Cumulus MX there are standard format codes (single characters) and custom format codes (combinations of characters, or single characters prefixed by %)
*The differences come about because Delphi is case-insensitive, while .NET and MONO are case sensitive.  Consequently, .NET (and MONO) can use upper and lower case for different items, but Delphi has to use different letters, ignoring case, for each item.
**The standard characters for dates and times are defined at [https://docs.microsoft.com/en-us/dotnet/standard/base-types/standard-date-and-time-format-strings standard-date-and-time-format-strings]
**The custom characters for dates and times are defined at [https://docs.microsoft.com/en-us/dotnet/standard/base-types/custom-date-and-time-format-strings custom-date-and-time-format-strings]
*In Cumulus MX the same character can have 4 different meanings depending on its case (capital letter or lower-case letter) and depending on whether it is on its own or not
**The case differences come about because Delphi is case-insensitive, while .NET and MONO are case sensitive.  Consequently, .NET (and MONO) can use upper and lower case for different items, but Delphi has to use different letters, ignoring case, for each item.


==== When it causes problems ====
==== When it causes problems ====


This can cause problems when somebody moves from using Cumulus 1 to using MX. They need to revisit any templates or scripts where they use output modifiers to specify a date and/or time format. We have already explored a very simple impact of this for [[Webtags#The_format_used_for_naming|NOAA report naming]].  
This can cause problems when somebody moves from using Cumulus 1 (C1) to using MX. They need to revisit any templates or scripts where they use output modifiers to specify a date and/or time format. We have already explored a very simple impact of this for [[Webtags#The_format_used_for_naming|NOAA report naming]]. There we were only concerned about how to represent a month.


For web tags it is much more complicated, not only do we need to select the right case, we also have to cope with MX selectors having different meanings when they are on their own and when they appear with other selectors, finally where you put quotes within these format specifiers varies between Cumulus 1 and MX partly because the reserved characters change and partly because MX introduces the concept of escaping characters.  
For web tags it is much more complicated, simply because it is not just month we may be representing, and we might require only one specifier (being careful whether we use a standard or custom modifier) or we might want to specify a combination of modifiers (and we might want to add a space character or other literals). It is difficult to summarise, but here are some potential issues:
* the reserved characters change between C1 and MX (affecting use of literals like "on" and "at" which are commonly required)
* MX introduces the concept of escaping characters
* in MX space in some cases may need to be within the single quotes containing other literals (as space can modify the interpretation of a modifier character).


'''Confused even more now?''' I'm not surprised, but maybe some examples will help before we actually list the available modifiers.
'''Confused even more now?''' I'm not surprised, but maybe some examples will help before we actually list the available modifiers.
Line 398: Line 413:
==== Forum reference ====
==== Forum reference ====


For official full details see [https://cumulus.hosiene.co.uk/viewtopic.php?f=39&t=17888 Cumulus MX forum], the following table is revised for simplicity. (I've given a different selection of combinations and included '%' where necessary to avoid single character versus custom complications). So "G" does not need a "%" because it is used on its own for a full date-time specifier. But "%d" is needed if only day number is required, but "d M" and "M" will both work to specify day number and month.
Steve Loft published a table showing comparison between output date modifiers for Cumulus 1 and MX at [https://cumulus.hosiene.co.uk/viewtopic.php?f=39&t=17888 Cumulus MX forum].  The table there was based  on the table that was originally here for just Cumulus 1.
 
The subsequent comments in the forum suggested his layout got people confused. Most of that confusion came in two circumstances:
*When someone wanted to use one date or time modifier on its own
*When someone who had been using Cumulus 1 swapped to MX and wanted to replace a combination of output modifier characters
 
That all comes from the fact that when a MX modifier consists of a single character it can mean something different to when it appears with other characters.  In Cumulus 1, "m" or "M" meant something different when it was combined with "H" or "h" (when it represented minutes), but in all other contexts it represented month. But for Cumulus 1, there is no other case where it matters what context a modifier is put in by the use of other modifiers, and no other modifier takes more than one meaning.
 
In MX it is much more complicated, to take a few examples "D", "H", "M" represent different items on their own to what they represent when combined with other characters.  That other character can be as simple as a space or a "%" which modify the meaning of the character. So my modification of the table below is with the intention of demonstrating what characters mean when they are on their own and what they represent in the context of being with other characters. Looking at the table you can see "G" is used on its own because it represents a full date-time specifier. "D" is similarly used on its own represents the long date format. If we only want the day of month number we must use "%d" to avoid the meaning of short date format that "d" on its own represents. If we want the typical Cumulus date-stamp of day of month number and month "d M" and "M" will both work because "M" has a different meaning on its own and with another modifier.


==== My Revised Table of Time and Date Output Modifiers ====
==== My Revised Table of Time and Date Output Modifiers ====
Line 411: Line 434:
|-
|-
|c
|c
|G
|G   (as single character format)
|Displays the date using the format given by the Short Date format, followed by the time using the format given by the Long Time format. The time is not displayed in Cumulus 1 if the date-time value indicates midnight precisely.
|Displays the date using the format given by the Short Date format, followed by the time using the format given by the Long Time format. The time is not displayed in Cumulus 1 if the date-time value indicates midnight precisely.
|'22/03/2019 09:47:25' produced by {{Version badge 1}}<#time format=c>[[File:Badge vMx.png]]<#time format=G>
|'22/03/2019 09:47:25' produced by {{Version badge 1}}<#time format=c>[[File:Badge vMx.png]]<#time format=G>
Line 437: Line 460:
|ddddd
|ddddd
|d (as single character format)
|d (as single character format)
|Displays the date using the format given by the Short Date format.
|Displays the date using the format given by the Short Date format.  [[File:Badge vMx.png]]The MX parameter cannot be combined with any other parameters.
|e.g. '22/03/2019' (British Locale) produced by {{Version badge 1}}<#metdate format="ddddd">[[File:Badge vMx.png]]<#metdate format="d">
|e.g. '22/03/2019' (British Locale) produced by {{Version badge 1}}<#metdate format="ddddd">[[File:Badge vMx.png]]<#metdate format="d">
|-
|-
|dddddd
|dddddd
|D
|D (as single character format)
|Displays the date using the format given by the Long Date format.
|Displays the date using the format given by the Long Date format.  [[File:Badge vMx.png]]The MX parameter cannot be combined with any other parameters.
|e.g. '22 March 2020' (British Locale)
|e.g. '22 March 2020' (British Locale)
|-
|-
Line 482: Line 505:
|Displays the hour (12 hour clock) without a leading zero (1-12) [optionally in combination with AM/PM]. What "tt" produces depends on locale settings for your device, it might be capitals or it might be lower case (in Windows use Control Panel, not Settings app, to get to these regional additional settings).
|Displays the hour (12 hour clock) without a leading zero (1-12) [optionally in combination with AM/PM]. What "tt" produces depends on locale settings for your device, it might be capitals or it might be lower case (in Windows use Control Panel, not Settings app, to get to these regional additional settings).
{{Version badge 1}}For Cumulus 1 the formats for am/pm depend on the case in which you type the parameter as shown later in this table
{{Version badge 1}}For Cumulus 1 the formats for am/pm depend on the case in which you type the parameter as shown later in this table
[[File:Badge vMx.png]]Note that including a ' ' (space) or '%' before the "h" makes it a custom modifier, that is not needed if the " tt" follows, as multiple parameters are always custom modifiers
|-
|-
|h:mm (or ''h:nn'') [''AM/PM'']
|h:mm (or ''h:nn'') [''AM/PM'']
Line 491: Line 516:
|H (or ''H'')
|H (or ''H'')
|%H
|%H
|Displays the hour using 24 hour clock without a leading zero (0-23). [[File:Badge vMx.png]]Note that % is only needed when H is on its own.
|Displays the hour using 24 hour clock without a leading zero (0-23). [[File:Badge vMx.png]]Note that including a ' ' (space) or '%' before the "H" makes it a custom modifier, needed because H is on its own.
|7 produced by {{Version badge 1}}<#daylength format=H>
|7 produced by {{Version badge 1}}<#daylength format=H>
[[File:Badge vMx.png]]<#daylength format=%H>
[[File:Badge vMx.png]]<#daylength format=%H>
Line 497: Line 522:
|H:mm (or ''H:nn'')
|H:mm (or ''H:nn'')
|H:mm
|H:mm
|Displays the hour using 24 hour clock without a leading zero (0-23) followed by 2 digit minutes. [[File:Badge vMx.png]]Note that % is not needed when H is not on its own.
|Displays the hour using 24 hour clock without a leading zero (0-23) followed by 2 digit minutes. [[File:Badge vMx.png]]Note that %, of previous example, is not needed when H is not on its own.
|'7:27' produced by <#LastDataReadT format="H:mm">
|'7:27' produced by <#LastDataReadT format="H:mm">
|-
|-
Line 512: Line 537:
|'07 am' produced by {{Version badge 1}} <#LastDataReadT format="hh am/pm">[[File:Badge vMx.png]] <#LastDataReadT format="hh tt">
|'07 am' produced by {{Version badge 1}} <#LastDataReadT format="hh am/pm">[[File:Badge vMx.png]] <#LastDataReadT format="hh tt">
|-
|-
|hh:mm (or ''hh:nn'') [''am/pm'']
|hh:mm (or ''hh:nn'' or 'HH:NN') [''am/pm'']
|hh:mm [''tt'']
|hh:mm [''tt'']
|Displays the hour (12 hour clock) with a leading zero (01-12) followed by 2 digit minutes [optionally in combination with am/pm].
|Displays the hour (12 hour clock) with a leading zero (01-12) followed by 2 digit minutes [optionally in combination with am/pm].
{{Version badge 1}}For Cumulus 1, the minutes can be represented by 'mm' only when in combination with 'h', in other contexts 'mm' is interpreted as month number, and the case output for am/pm depends on the case used for that parameter as shown later in this table
{{Version badge 1}}For Cumulus 1, the minutes can be represented by 'mm' only when in combination with 'h', in other contexts 'mm' is interpreted as month number, and the case output for am/pm depends on the case used for that parameter as shown later in this table. As Cumulus 1 is case insensitive there are variants with capital letters available.
[[File:Badge vMx.png]] For MX, the optional 'tt' displays the contents of the device locale setting for AM string for midnight until any hour before noon, and the contents of the PM string for noon or any hour after noon before midnight
[[File:Badge vMx.png]] For MX, the optional 'tt' displays the contents of the device locale setting for AM string for midnight until any hour before noon, and the contents of the PM string for noon or any hour after noon before midnight
|'8:27 am' produced by {{Version badge 1}} <#LastDataReadT format="h:nn am/pm">[[File:Badge vMx.png]] <#LastDataReadT format="h:mm tt">
|'8:27 am' produced by {{Version badge 1}} <#LastDataReadT format="h:nn am/pm">[[File:Badge vMx.png]] <#LastDataReadT format="h:mm tt">
Line 531: Line 556:
|s
|s
|%s
|%s
|Displays the second without a leading zero (0-59). [[File:Badge vMx.png]] As other examples show, the % is only needed when "m" is on its own.
|Displays the second without a leading zero (0-59). [[File:Badge vMx.png]] As other examples show, the % is recommended when "s" is on its own, although I have not found any alternative meaning for "s" on its own.
| 9
| 9
|-
|-
Line 541: Line 566:
|z
|z
|FFF
|FFF
|Displays the millisecond without a leading zero (Cumulus 1:0-999, Cumulus MX: nothing, or 1-999). Note that the system clock in some versions of Windows only has precision to 15 ms.
|Displays the millisecond without a leading zero (Cumulus 1: displays 0-999, Cumulus MX: displays either nothing, or displays 1-999, so don't write any code that assumes the MX output is numeric).  
 
Note that the system clock in non-current versions of Windows only has precision to 15 ms, so don't use this modifier if your Cumulus is running on an old version of Windows.
|  
|  
|-
|-
Line 553: Line 580:
|Displays the millisecond with a leading zero (000-999). Note that the system clock in some versions of Windows only has precision to 15 ms, so requesting thousandths of a second may not return anything useful.  
|Displays the millisecond with a leading zero (000-999). Note that the system clock in some versions of Windows only has precision to 15 ms, so requesting thousandths of a second may not return anything useful.  


The 'fff' modifier in MX can actually be extended to 'ffffff' for output to a millionth of a second!
[[File:Badge vMx.png]]The 'fff' modifier in MX can actually be extended to 'ffffff' for output to a millionth of a second!
| 09:47:25.000' produced by {{Version badge 1}}<#time format=hh:nn:ss.zzz>[[File:Badge vMx.png]]<#time format=hh:mm:ss.fff>
| 09:47:25.000' produced by {{Version badge 1}}<#time format=hh:nn:ss.zzz>[[File:Badge vMx.png]]<#time format=hh:mm:ss.fff>
|-
|-
|(not available)
|(not available)
|0zzz
| zzz
|Displays the offset of any time from UTC in hours and minutes
|Displays the offset of any time from UTC in hours and minutes
| e.g.-07:00
| e.g.-07:00
|-
|-
Line 572: Line 599:
|-
|-
|TT
|TT
|T
|T (as single character format)
|Displays the time using the Long Time format. [[File:Badge vMx.png]] Note that this is a full time specifier and "T" does not need a "%" although it is on its own.
|Displays the time using the Long Time format. [[File:Badge vMx.png]] Note that this is a full time specifier and "T" is on its own as we are using a single character format.
|'09:47:56'  (might not use colon in your locale) produced by {{Version badge 1}}<#LastDataReadT format=TT> [[File:Badge vMx.png]]<#LastDataReadT format=T>
|'09:47:56'  (might not use colon in your locale) produced by {{Version badge 1}}<#LastDataReadT format=TT> [[File:Badge vMx.png]]<#LastDataReadT format=T>
|-
|-
Line 580: Line 607:
|{{Version badge 1}}Uses the 12-hour clock for the preceding h or H specifier, and displays 'am' for any hour from midnight until just before noon, and 'pm' for any hour from noon onwards. The am/pm specifier for Cumulus 1 can use lower, upper, or mixed case, and the result is displayed accordingly.
|{{Version badge 1}}Uses the 12-hour clock for the preceding h or H specifier, and displays 'am' for any hour from midnight until just before noon, and 'pm' for any hour from noon onwards. The am/pm specifier for Cumulus 1 can use lower, upper, or mixed case, and the result is displayed accordingly.


[[File:Badge vMx.png]] For MX, 'tt' displays the contents of the device locale setting for AM string for midnight until any hour before noon, and the contents of the PM string for noon or any hour after noon before midnight
[[File:Badge vMx.png]] For MX, 'tt' displays the contents of the device locale setting for AM string for midnight until any hour before noon, and the contents of the PM string for noon or any hour after noon before midnight, so whether it displays in capitals or lower case is determined by the locale settings, not the case of "tt".
| {Version badge 1}} 'am' produced by <#LastDataReadT format=am/pm>, 'AM' produced by <#LastDataReadT format=AM/PM>
| {Version badge 1}} 'am' produced by <#LastDataReadT format=am/pm>, 'AM' produced by <#LastDataReadT format=AM/PM>
|-
|-
|a/p
|h a/p
|%t
|h t
|Uses the 12-hour clock for the preceding h or H specifier, and displays 'a' for any hour from midnight until before noon, and 'p' for noon or any hour after noon.
|Uses the 12-hour clock for the preceding h or H specifier, and displays 'a' for any hour from midnight until before noon, and 'p' for noon or any hour after noon.
{{Version badge 1} The a/p specifier can use lower, upper, or mixed case, and the result is displayed accordingly.
{{Version badge 1} The a/p specifier can use lower, upper, or mixed case, and the result is displayed accordingly.
[[File:Badge vMx.png]]Remember that 't' has to be combined with other specifiers (or preceded by space or '%') to display 'a' or 'p' as if it is alone it has a different (short format time) meaning - see above.
 
[[File:Badge vMx.png]]whether it displays the "a" or "p" in capitals or lower case is determined by the locale settings, not the case of "t".
| see previous example
| see previous example
|-
|-
Line 603: Line 631:
|:
|:
|:
|:
|Displays the time separator character given by the Time Separator. It might not display a colon.
|Displays the time separator character given by the Time Separator. With Cumulus 1, this might not display a colon.
 
[[File:Badge vMx.png]]Note that by default Cumulus MX expects a locale to use ":" for any time separator.
|':' for British locale
|':' for British locale
|-
|-
|'xy'
|'xy'
|'xy' or ''\x\y''
|'xy' or ''\x\y''
|Characters enclosed in single quotation marks are displayed as such, and do not affect formatting. In MX each character to be displayed as it was typed can be prefixed by a backslash.
|Characters enclosed in single quotation marks are displayed as such, and do not affect formatting.  
 
[[File:Badge vMx.png]]In MX each character to be displayed as it was typed can be prefixed by a backslash. Also remember that any spaces in a MX modifier might need to be within single quotes as space is also used to change what a modifier represents. I told you MX modifiers were more complicated!
|Hyphens are added in this PHP language example  '<#LastDataReadT format=yyyy>'.'-'.'<#LastDataReadT format=MM>'.'-'.'<#LastDataReadT format="dd">'
|Hyphens are added in this PHP language example  '<#LastDataReadT format=yyyy>'.'-'.'<#LastDataReadT format=MM>'.'-'.'<#LastDataReadT format="dd">'
|}
|}
Line 654: Line 686:




=The web tag application programming interface=
[[File:Badge vMx.png]] Available from version 3.7.0 (build 3089) released 28 July 2020. It was proposed in January 2015, see Steve Loft [https://cumulus.hosiene.co.uk/viewtopic.php?p=101496#p101496 plan to add a call where you supply a list of items (probably web tag names), and you get back the equivalent data].
== Where to use ==
This is meant for services either on the same computer as Cumulus or on your local network. It is not secure, and should not be available, nor requested, via any external network or the internet.
The [[MX Administrative Interface]] uses some application programming interface (api) calls to obtain the data each web page in that interface needs, and another api to return the results of any edit made. If you wanted your '''CumulusMX/interface/todayyest.html''' web page to include something else (e.g. snow falling/lying/depth) you would edit that HTML page to have the extra sub-table you want (you cannot extend the existing rainfall table as that is dynamically created by existing api) and you would edit the associated JavaScript file '''CumulusMX/interface/js/todayyest.js''' to add a new api call seeking snowdepth, snowfalling, snowlying tags for today (unfortunately there are no tags for yesterday's snow) and to place the returned values into your new sub-table (probably using jQuery to make it easy). In a similar way, you could add anything where today and yesterday tags are available such as UV Index.
In earlier versions of Cumulus if you wanted to make use of values processed by Cumulus, you wrote a script file referencing the web tags you wanted to use, and let Cumulus process that file at an interval set in the settings, then you had to write something to process the results at the relevant interval. Now if you are running other software on your device that runs MX (or a computer or other device linked directly on your personal network), you can request web tags values on demand via an application programming interface (api hereafter) and don't need to worry about any timing issues.
Obviously each api request creates a processing overhead on Cumulus so use this feature wisely (minimise the information you request and minimise the frequency of requesting it). You can use it for extra current information, but in that usage you might need to repeat the call. Consequently, maybe it is more likely that the api will be used to request information that does not keep changing, such as what units are being used for temperature, rainfall, and wind speed; or perhaps daily, monthly, or yearly, summary figures.
Each admin interface web page uses api techniques for all the information it needs. Some api calls are repeated with AJAX requesting updates for the weather information on a frequent basis, but each page has another api request that is issued just once for the version and build being used.  To my mind, the design of '''CumulusMX/interface/todayyest.html''' is crazy.  The HTML appears to have a table structure, but that table structure is overwritten by each repeating api. So every time AJAX repeats that api call it returns in json format the whole table definition as well as table cell contents, despite that much of that json (all that HTML defining table header, table rows, table cells, etc.; and the units for each value) does not change and it is only some values and times buried within the json in the api that actually might change (and of those half of them, the yesterday values and times only change once a day).  In some code I wrote (but later abandoned) I made use of the api calls that support the '''CumulusMX/interface/todayyest.html''' web page to get the units I wanted on another interface page, but I only called it once as it returned a lot of other information (as just mentioned) that I did not need. I later found a better way, as in example below, which gives me just what I need and no more.
== "GET" approach ==
You may have used GET as an attribute when defining the action of a HTML form.  Equally you might in a script language access the query-string part of a Universal Resource Locator to get parameters for what the script is to supply to the web page.  Even if you don't understand the meaning of those technical terms, you probably have seen when using a browser (in the box where a URL is entered) that sometimes the URL seen there has a query-string. You will have seen a question mark (?) followed by one or [separated by ampersand (&)] more '''name=value''' parameters.
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===
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 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>
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.
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.
=== JavaScript example ===
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. 
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.
Here is the code (with the api call written using jQuery):
<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 ==
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.
You may have used POST as an attribute when defining the action of a HTML form.  In that context the form is sent as the contents of a message to whatever web page is going to process the contents of that form. 
The post approach has a few advantages over get:
*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


=The Web Tags for Cumulus =
=The Web Tags for Cumulus =
Line 663: Line 786:
== System ==
== System ==


Special tags returning information about the Windows device hosting Cumulus 1. ''If you are running MX, then most tags do not work.
Special tags returning information about the Windows device hosting Cumulus 1.  
''
 
[[File:Badge vMx.png]]''If you are running MX, then most tags do not work.''


{| class="wikitable" border="1"
{| class="wikitable" border="1"
Line 909: Line 1,033:
[[File:Badge vMx.png]]Available from version 3.5.2
[[File:Badge vMx.png]]Available from version 3.5.2


The JavaScript '''Date''' object contains the number of miliseconds since 00:00:00.000 UTC on 1st January 1970, that date and time is known as the UNIX Epoch.  In JavaScript, you can use <tt>Math.floor(new Date().getTime()/1000.0)</tt> This getTime method returns the time in milliseconds.  The web tag returns an integer (currently with 13 digits) representing the number of milliseconds since the UNIX epoch when the web tag was processed. It can be used in a script where you wish to re-express other times output by Cumulus MX into UTC (Coordinated Universal Time).  Mac OS X uses 00:00:00.000 UTC on 1st January 2001 as the starting time and date for its millisecond count, so that is considerably lower.
Note that UTC is calculated using 9192631770 times a particular transition time for Caesium 133 as a basis for 1 second. GMT (Greenwich Mean Time) is calculated on the basis that 1 second is 1/86400 of the time taken for a whole (day) rotation of the Earth. UT1 (or solar time) is calculated from various space measurements. Periodically, leap seconds are added to UTC to realign it with UT1, but these leap seconds are not added to the count of milliseconds represented by this web tag.
Do be aware that some devices will use a 32 bit signed integer to represent this number, and that will stop working on 19 January 2038, the year 2038 problem for computing world.
|-
|-
|<#timeUnix>
|<#timeUnix>
Line 915: Line 1,044:
[[File:Badge vMx.png]]Available from version 3.7.0
[[File:Badge vMx.png]]Available from version 3.7.0


Same as previous, it provides the last update time as a Unix timestamp - which is since 1 Jan 1970.
Unix tracks the number of seconds since the UNIX epoch. So this web tag can be used when you do not want the millisecond accuracy of the previous web tag. Like previous web tag this relates to UTC, so see details for that tag to find out more. This is equivalent in PHP 5 and PHP 7 to '''time();''' (in PHP 8, a parameter is mandatory for time function, so the call changes).
 
The unix time stamp is a way to track time as a running total of seconds. This count starts at the Unix Epoch on January 1st, 1970 at UTC. Therefore, the unix time stamp is merely the number of seconds between a particular date and the Unix Epoch. It should also be pointed out (thanks to the comments from visitors to this site) that this point in time technically does not change no matter where you are located on the globe. This is very useful to computer systems for tracking and sorting dated information in dynamic and distributed applications both online and client side.
 
Note that it stops working on 19 Jan 2038, unless the device that MX is running on, and the web server where this tag is viewed, use 64 bit or better technology.
|-
|-
|<#LastDataReadT>
|<#LastDataReadT>
|The date/time data was last read from the station
|The date/time data was last read from the station. Default format for this tag is like this example '''18:30 on 30 December 2009''', but output parameters for both date and time can modify this to include seconds in 1.9.x builds and most MX builds such as per this example  '<#LastDataReadT format="yyyy-MM-dd HH:mm:ss">'.
|-
|-
|<#DaysSince30Dec1899>  
|<#DaysSince30Dec1899>  
Line 928: Line 1,053:
|-
|-
|<#recordsbegandate>
|<#recordsbegandate>
|Date when records began (appears twice on "recordsT.htm" provided, and used to calculate next tag, but ignored for all other Cumulus processing)
|Date when records began (appears twice on "recordT.htm" provided in standard web page, and used to calculate next tag, but ignored for all other Cumulus processing). Any output parameters valid for a date can be used here, don't forget differences in modifiers for Cumulus 1 and MX. There is no time associated with this web tag.  The default format is like 30 December 2009, please note although this web tag reports the value associated with  [b]StartDate=dd/MM/yyyy[/b] (see [[Cumulus.ini#Section:_Station]]), the format there is short-date format and different to default format for this web tag.
|-
|-
|<#DaysSinceRecordsBegan>
|<#DaysSinceRecordsBegan>
Line 2,635: Line 2,760:
|<#DataStopped>
|<#DataStopped>
|1 if the station has apparently stopped sending data to Cumulus, otherwise 0
|1 if the station has apparently stopped sending data to Cumulus, otherwise 0
|-
|<#DataSpikeAlarm>
|[[File:Badge vMx.png]] Available from version 3.7.0
Alarm raised if a data spike is detected, or a data limit exceeded
|}
|}


Line 2,879: Line 3,008:
|<#DavisReceptionPercent tx=1>
|<#DavisReceptionPercent tx=1>
|WLL transmitter reception percentage (replace 1 by any other transmitter number up to 8)
|WLL transmitter reception percentage (replace 1 by any other transmitter number up to 8)
|-
|<#DavisTxRssi tx=0>
|WLL RSSI of the WiFi connection
|-
|-
|<#DavisTxRssi tx=1>
|<#DavisTxRssi tx=1>
|WLL WiFi RSSI
|WLL RSSI of Transmitter #1  (replace 1 by any other transmitter number up to 8)
|}
|}


Sfws
5,838

edits

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

Navigation menu