Data Inputs to Savings Estimate
===============================
DHD20160302


External Demand Data
--------------------

1) Daily heating-degree days (from degreedays.net).


Energy Use Data
---------------

1) Hourly gas consumption (kWh) via the Loop sensors.


Data collected from the valve/sensor nodes
------------------------------------------

Typically a rotating subset of the values is sent about every 4 minutes
with changing values sent more often and 'low-priority' values less often,
and samples can be lost due to radio noise, etc.

A typical sample from log files:

[ "2016-02-18T10:45:40Z", "", {"@":"414a","+":2,"L":130,"vC|%":1158,"T|C16":255} ]
[ "2016-02-18T10:46:10Z", "", {"@":"2d1a","+":4,"L":78,"T|C16":326,"O":2,"vac|h":0} ]
[ "2016-02-18T10:46:13Z", "", {"@":"0d49","+":4,"L":238,"T|C16":265,"O":1,"vac|h":2} ]
[ "2016-02-18T10:46:59Z", "", {"@":"b6d9","+":7,"L":177,"T|C16":298,"H|%":67,"O":1} ]
[ "2016-02-18T10:48:25Z", "", {"@":"819c","T|C16":80,"L":223,"B|cV":251} ]
[ "2016-02-18T10:49:13Z", "", {"@":"0d49","+":5,"B|cV":259,"L":238,"v|%":0,"tT|C":6} ]
[ "2016-02-18T10:49:37Z", "", {"@":"414a","+":3,"O":1,"vac|h":2,"B|cV":257,"L":135} ]
[ "2016-02-18T10:50:52Z", "", {"@":"3015","+":4,"T|C16":295,"v|%":0,"tT|C":17} ]
[ "2016-02-18T10:50:53Z", "", {"@":"0a45","+":5,"tT|C":16,"vC|%":2322,"T|C16":283} ]
[ "2016-02-18T10:52:25Z", "", {"@":"819c","T|C16":80,"L":234,"B|cV":251} ]

This log file is a series of lines, each a JSON array,
of which the first field is a UTC timestamp
and the third is the JSON object as sent by the remote device
(eg valve or sensor).
Almost all values are non-negative decimal integer, a few are string.
Precision is usually but not always effectively one unit in the last place,
ie all digits should be meaningful.

The general format is x|u where x is the name and u are the UCUM units.
Non-UCUM units are used in some very common cases for brevity/clarity.
Units are omitted entirely where not applicable eg device is uncalibrated.

(Note that Celsius temperature values use 'C' rather than 'Cel'
to save bandwidth, though this is strictly speaking incorrect,
since 'C' is intended for coulomb.)

Meaning of the various common JSON fields:

L     light level 0--255 (uncalibrated)
vC|%  valve movement Cumulative | %
T|C16 (room) temperature | Celsius * 16 (ie 16ths of a degree C)
O     Occupancy (0 unknown, 1 vacant, 2 possibly occupied, 3 defintiely occupied)
vac|h vacancy time | hours
H|%   relative Humidity | %
B|cV  battery voltage | centiVolts
v|%   valve-open | %
tT|C  target room temperature (with auto setbacks) | Celsius
tS|C  setback in direction energy saving (eg lowered target for heating)

"@"   Node ID prefix in hex
"+"   frame sequence number (used to help detect lost frames/data)

Often the following are low priority as they are redundant
(can be deduced from other values) or should change slowly:
    vC|%, vac|h, B|cV, tS|C

In particular, tS|C should provide a fairly direct nominal potential saving,
with comparison against actual room temperature and valve position to moderate
that view.


Associations
------------

Note that our data model groups sensors by ID into households,
and associates those households with a weather station for the HDD data.


Before and After
----------------

In general valves installed will start in "dumb" mode for ~1 week,
ie not doing any automatic setbacks
so that the user's default usage pattern can be monitored
(and the device gets a chance to learn that pattern properly),
and automatically switch to 'smart' mode after that time.
The user is not told exactly when that happens.

We will then have an automatic initial baseline.



Call Notes from 2016/03/03
==========================

Next stage will be for NPL to summarise/extract relevant best practice etc
from standards such as ISO 50006 & 50015, plus correct statistical treatment.

DHD will write short doc with three parts:

 1) Device callibration and traceability.
    Energy probably most critical, so for example,
    verifying start and end readings from Loop against supply meters
    demonstrates a chain and accuracy there.

    Also can describe component calibration etc (SHT21) from datasheets.

    Also probably ought to provide chain for HDD.

 2) Include/reference stds/stats summary from NPL.

 3) Summarise method/protocol based on data/inputs document and (1) and (2)
    as skeleton/draft to agree.