Appliance, Appliance Type and Prior metadata usage questions

[gjwo]

see also issue #19. and nilmtk issue #413 "Storing appliance fingerprints/signatures/priors needs definition". Note paragraph numbers should be 1.2.3.4 below
I am trying to work out how to use metadata in conjunction with Hart'85 training and disaggregation, this has led to a closer examination of the metadata definitions to save reinventing any wheels. I have the following questions

1. Why is dominant appliance required, this would seem logical for sub-meter aimed at measuring a particular appliance, but inappropriate for a whole house meter where you may not know what the dominant appliance is, or it may change with time

dominant_appliance: 
(boolean) (required if multiple appliances attached to one meter). Is this appliance responsible for most of the power demand on this meter?

1. Usage of "on_power_threshold" and "nominal_consumption", (see definitions below) Is it intended that "on_power_threshold" be used to hold a more accurate (measured) on power value for the appliance for use in matching with training results as opposed to the manufacturer's view?

on_power_threshold:
(number) watts. Not required. Default is taken from the appliance type. The threshold (in watts) used to decide if the appliance is on or off.

nominal_consumption:    
(dict): Specifications reported by the manufacturer.

on_power:   (number) active power in watts when on.
standby_power:  (number) active power in watts when in standby.
energy_per_year:
    (number) kWh per year
energy_per_cycle:
    (number) kWh per cycle

1. Priors are defined for Appliance Types, rather than for Appliances, which is OK for the way they are defined in terms of statistical relationships between appliance types and between appliance types and general usage patterns. However if my interpretation of "on_power_threshold" above is correct, then this is in fact being used as a defacto appliance specific prior and it would be better to define this in a way that could be used by the disaggregation algorithms, and call it a Prior or Signature or Fingerprint and allow Appliances to link to Priors in a similar way to Appliance Types.
2. As discussed in nilmtk issue #413 a set of the steady states of power usage of an appliance could constitute a simple Prior or Signature or Fingerprint - to avoid confusion it might be better to call it a Signature rather than a Prior, this would keep the separation between central and dataset metadata. The definition of a Signature might look like this if part of appliance data

signature: (list of dicts) #steady_states this appliance can have
steady_state: (dict of power_values) #one or more of the power characteristics of this state
active: (number) #active power in Watts
reactive:   (number) #reactive power in VAR
apparent:   (number) #apparent power in VA
#so we might have
- original_name: Kettle
  description: stainless steel 2.5-3kw Hinged locking lid ; 360 degree base; One Cup Indicator
  manufacturer: Philips
  model: HD4671
  type: kettle
  room: kitchen
  meters: [1] 
  nominal_consumption: {on_power: 3000}
  on_power_threshold: 3000
  instance: 1
  signature: {active: 2900, reactive:0}

A signature may need to specify a tolerance or distribution of values as discussed for Priors, and a duration range for the steady state.

[JackKelly]

Why is dominant appliance required, this would seem logical for sub-meter aimed at measuring a particular appliance, but inappropriate for a whole house meter where you may not know what the dominant appliance is, or it may change with time

All correct. dominant_appliance is only meant to be used for submeters.

1. Your proposal for a signature looks good. But it would be good to handle multiple states per appliance. But then life gets trickier. Maybe something like this:

- type: washer dryer
  instance: 1
  signature: 
    - {state_name: 'off',  active:    0, reactive:   0}
    - {state_name: 'soak', active:  100, reactive:  50}
    - {state_name: 'heat', active: 2500, reactive:  50}
    - {state_name: 'spin', active:  200, reactive: 100}

I haven't given this a huge amount of thought so by all means modify!

@nipunreddevil, any comments?

[gjwo]

That seems entirely sensible, building on that

- type: washer dryer
  instance: 1
  signature: 
    - {state_name: 'off',  active:    0, reactive:   0}
    - {state_name: 'soak', active:  100, reactive:  50, min_duration:60, max_duration:600}
    - {state_name: 'heat', active: 2500, reactive:  50, active_tolerance: 200, reactive_tolerance:40}
    - {state_name: 'spin', active:  200, reactive: 100, ramped: True}