Central appliance metadata¶
Manual¶
Please see the NILM Metadata README section on ‘Central metadata’ for a quick introduction.
Inheritance¶
- protypical inheritance; like JavaScript
- dicts are updated; lists are extended; other properties are overwritten
- arbitrary inheritance depth
Components¶
- recursive
- categories of container appliance is updated with categories from
each component (unless
do_not_merge_categories: true
is set in the component)
Subtypes versus a new child object¶
Appliance specification objects can take a ‘subtype’ property. Why not use inheritance for all subtypes? The rule of thumb is that if a subtype is functionally different to its parent then it should be specified as a separate o child bject (for example, a gas hob and an electric hob clearly have radically different electricity usage profiles) but if the differences are minor (e.g. a digital radio versus an analogue radio) then the appliances should be specified as subtypes of the same object.
Naming conventions¶
- properties are lowercase with underscores, e.g. subtype
- object names (not specific makes and models) are lowercase with spaces, unless they are acronyms in which case they are uppercase (e.g. ‘LED’)
- category names are lowercase with spaces
Example¶
To demonstrate the inheritance system, let’s look at specifying a boiler.
First, NILM Metadata specifies a ‘heating appliance’ object, which is can be considered the ‘base class’:
heating appliance:
parent: appliance
categories:
traditional: heating
size: large
Next, we specify a ‘boiler’ object, which inherits from ‘heating appliance’:
#------------- BOILERS ------------------------
boiler: # all boilers except for electric boilers
parent: heating appliance
synonyms: [furnace]
# Categories of the child object are appended
# to existing categories in the parent.
categories:
google_shopping:
- climate control
- furnaces and boilers
# Here we specify that boilers have a component
# which is itself an object whose parent
# is `water pump`.
components:
- type: water pump
# Boilers have a property which most other appliances
# do not have: a fuel source. We specify additional
# properties using the JSON Schema syntax.
additional_properties:
fuel:
enum: [natural gas, coal, wood, oil, LPG]
subtypes:
- combi
- regular
# We can specify the different mechanisms that
# control the boiler. This is useful, for example,
# if we want to find all appliances which
# must be manually controlled (e.g. toasters)
control: [manual, timer, thermostat]
# We can also declare prior knowledge about boilers.
# For example, we know that boilers tend to be in
# bathrooms, utility rooms or kitchens
distributions:
room:
distribution_of_data:
categories: [bathroom, utility, kitchen]
values: [0.3, 0.2, 0.2]
# If the values do not add to 1 then the assumption
# is that the remaining probability mass is distributed equally to
# all other rooms.
source: subjective # These values are basically guesses!
Finally, in the metadata for the dataset itself, we can do:
type: boiler
manufacturer: Worcester
model: Greenstar 30CDi Conventional natural gas
room: bathroom
year_of_purchase: 2011
fuel: natural gas
subtype: regular
part_number: 41-311-71
efficiency_rating:
certification_name: SEDBUK
rating: A
nominal_consumption:
on_power: 70
Schema details¶
Below is a UML Class Diagram showing all the classes and the relationships between classes:
(Please see the NILM Metadata Tutorial for more background about the NILM Metadata schema)
Below we describe all the classes and their attributes and possible values.
ApplianceType¶
Has many of the attributes that Appliance has, with the addition of:
- on_power_threshold
- min_off_duration
- min_on_duration
- control
- components
parent: | (string) Name of the parent ApplianceType object from which this object inherits. |
||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
categories: | (dict)
|
||||||||||||
subtypes: | (list of strings) A list of all the valid subtypes. |
||||||||||||
additional_properties: | |||||||||||||
(dict) Used for specifying additional properties which can be specified for Appliances of this ApplianceType. Each key is a property. Each value is a JSON Schema definition of the property. |
|||||||||||||
do_not_inherit: | (list of strings) properties which should not be inherited from the parent. |
||||||||||||
synonyms: | (list of strings) |
||||||||||||
usual_components: | |||||||||||||
(list of strings) Just a list of hints for human readers. |
|||||||||||||
n_ancestors: | (int) Filled in by |
distributions: | (dict) Distribution of random variables.
|
---|
Country¶
One large dict specifying country-specific information. Specified in
nilm_metadata/central_metadata/country.yaml
Each key is a ‘country’ (string). Please use a standard two-letter country code defined by ISO 3166-1 alpha-2. e.g. ‘GB’ or ‘US’.
Each value is a dict with the following attributes:
mains_voltage: | (dict):
|
---|
Prior¶
Represent prior knowledge. For continuous variables, specify either the distribution of data (i.e. the data represented in a histogram), or a density estimate (a model fitted to the data), or both. For categorical variables, specify the categorical distribution.
distribution_of_data: | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||
model: |
|
||||||||||
n_datapoints: | (int) |
||||||||||
date_prepared: | (string) ISO 8601 date format |
||||||||||
source: | (enum) one of {‘subjective’, ‘empirical from data’,
‘empirical from publication’}. What is the source of this
prior? If from publication then use |
||||||||||
related_documents: | |||||||||||
(list of strings) If ‘source==empirical from publication’ then enter the reference(s) here. |
|||||||||||
software: | (string) the software used to generate the prior from data. |
||||||||||
specific_to: | (dict):
|
||||||||||
distance: | (int) this is filled in by the
|
||||||||||
from_appliance_type: | |||||||||||
(string) this is filled in by the
|
|||||||||||
description: | (string) |
||||||||||
training_data: | (array of dicts). Each element is a dict with these properties:
|
DisaggregationModel¶
This is not especially well defined yet. Just an initial sketch. The basic idea is that we would be able to specify models for each appliance type.
appliance_type: | (string) Reference to the specific ApplianceType that we are modelling. |
---|---|
model_type: | (enum) one of {‘HMM’, ‘FHMM’, ‘gubernatorial optimisation’} |
parameters: | (dict) Parameters specific to each model type. |
DisaggregationModel re-uses several properties from Prior :
- training_data
- specific_to
- software
- related_documents
- date_prepared
- description