/config/var

Meter variables provide a means to store arbitrary name/value pairs on the meter itself. These variables can be employed by a WebAPI user to customize behavior. For example, the preferred currency symbol is stored in a meter variable so that all WebAPI users can consistenty display monetary values.

Any authenticated user can read meter variables but only users who have the privilege to save settings can create or update them.

Variable names must be at least one character long and may consist of lower- and upper-case ASCII letters, digits, dashes (-), underscores (_), and percent signs (%). Note that when using a variable name as part of a URL path, any percent sign must be encoded as %25 (25 is the hexadecimal value of the ASCII code of %).

For backwards-compatibility, a variable name may also contain a single dot (.) if it does not appear as the first or last character in the name. When a dot is present, the string before the dot is called the paragraph name.

Variable values may contain any UTF-8 points except ASCII control characters.

Meter variables are organized into sections. Each section has a name and contains zero or more variables. Typically, groups of related meter variables are stored together in a single section. Variables can be accessed individually or by section.

For example, the global section contains variables that apply to the meter in general, such as billing information or the currency symbol to use for monetary values. Other sections are specific to particular applications (in the widest sense of the word). For example, the health section contains variables that define the behavior of the meter's health checker service.

Section names must be at at least 1 and at most 63 bytes long and may consist of lower- and upper-case ASCII letters, digits, dashes (-), underscores (_), and percent signs (%).

What distinguishes meter variables from normal configuration settings is that the former are generally not used by the meter firmware. In other words, meter variables are used primarily by users of WebAPI. There are a few exceptions, however, for the global section:

• billing.interval: The meter firmware interprets this as the length of the demand interval in minutes (see description of /register query parameter demand).

• billing.start_day: The meter firmware interprets this as the day of the month on which the utility company reads the utility meter. The assumption is that the meter is read at noon on that day. The value must be a decimal integer string in the range from 1-31. If the billing day number is greater than the number of days in a particular month, it is assumed that utility meter is read on the last day of that month.

  The meter-firmware uses this, for example, to implement the sob time point.

• billing.tariff_uri: If not an empty string, this is interpreted as the URL from which to fetch a Lua script that calculates energy cost. The meter will periodically poll this URL and download any available updates to the script.

• default.currency_symbol: This is interpreted as the symbol to use for currency values. This may be a single Unicode symbol such as $ (Dollar) or € (Euro), or it may be a multi character string, such as CHF for Swiss Franc. The meter firmware uses the value of this variable when outputting the unit of monetary values.