TOWARDS LIVE, CONTINUOUS BUILDING ENERGY AUDITS Recording and Managing Building Plug-load Information Jorge Ortiz and Jason Trager LoCal Retreat June 1, 2011

Many miscellaneous loads  Plugs loads can account for almost the other 50% of energy spend in the building  Opportunity for savings:  Plug loads may be controlled locally either by user of by demand-response signal  Metering and collecting this data takes long  Many sources distributed throughout the building

Energy audits today  Can range from simple building walk-through to analysis of energy use (electric bill)  Comparison made to similar buildings  Most sophisticated audits may use install metering and offline building modeling

Rapid Auditing Protocol (RAP) 4  Tag everything with a QR code  Scan Device QR code (unique for each device)  Bind QR code with device/item  Bind meters and devices  Record Device information  Performed audit in Sutardja Dai Hall

Recording spatial context Global Origin (3,0,0)  Building coordinate system (foot by foot)  Origin: Southwest corner of SDH

RAP Interface 6  Android App  Easily used  Shallow learning curve (356MN,8,2) (356MN,8,8)

Environment and Activity /SodaHall /hvac /CT /Chiller /loadtree /panel /xform /spaces /floor3 /floor4 Electrical Load Tree Climate plant StreamFS: Metadata organization 7 Structured, Traversable namespace Multiple building views

StreamFS: Query system architecture 8 /inventory/mote123 DB PID 1 PID 2 PID 3 PID 4 Time GET ?query=true&ts_timestamp=gt:now-100,ls=now GET /SDH/spaces/*?query=true&props_metertype=powermeter { “metertype”:”powermeter”, “desc”:”Electric power meter”, “timestamp”: } /power /temp/hum/par

Audit metadata organization /is4 /buildings /taxonomies /SDH /qrc /mels /Electronics /Miscellaneous /other /inventory /spaces LBNL Taxonomy

Recorded Information  Basic info  Power Usage, placement, device power draw or amperage rating, device make and model number  Device Type (taxonomy)  Provided by LBNL  Extra information

Initial Rapid Auditing Results TypeComputerElectronic Desks LampLaser Printer LCD Monitor Notebook Computers PhonesImacResistiv e Loads MicrowavesOther Count Power Use

RAP / StreamFS Data pulled from StreamFS Building Rooms Plotted Static Power use Easily understood Tap into people’s perceptions Give estimations of energy use

Upcoming work  Map to other building views (electrical, HVAC)  Track deployment evolution  Integrate live metering  Tap into the “Weak Actuator” – People  Live alerts and visualizations  Address Coverage  How many sensors are needed to capture energy picture?  Use audit to investigate DR Variations  How is our scenario unique?

Tracking deployment evolution  Metadata organization  Typically static, now live.  Streaming data from meters Items attached to those meters changes  Meters move as well Moved to new locations Attached to different items  How do we keep accurate view of where energy is going and how it is being consumed?  Context-related queries: One-off queries on current state Live queries that account for state transitions

Metadata graph  Acyclic graph of namespaces for building views /SDH /inventory { “desc”:”invento ry inside SDH” “timestamp”: … } {“desc”:”Lamp” “timestamp”: …} {“desc”:”Phone ” “timestamp”: …} {“desc”:”Outlet ” “timestamp”: …} {“desc”:”Acme” “timestamp”: …} r-node s-node /hvac /CT /Chiller /vent /loadtree /panel /xform /outlet /spaces /floor3 /floor4 /power /mote123

Typical subscription  /buildings/SDH/floor3/364/LCD/power |  String match on source data  Data POSTed to ‘ /buildings/SDH/floor3/364/LCD/power ’ tagged on entry  Tag used to match against subscriptions and pushed to matches

Dynamic subscription  /buildings/SDH/floor3/364/* |  Still a simple match of the wildcard source string  What about relevant data that whose ingress tag does not match?  i.e. If a mobile power meter is measuring LCD in room 364 and it is placed in another folder (i.e. /inventory) Incoming data tag will not match wildcard expression POST /inventory/meter

Dynamic subscription (2)  Using the metadata graph  Check match and path existence  /buildings/SDH/floor3/364/LCD/power (symlink) /SDH /inventory { “desc”:”inve ntory inside SDH” “timestamp” : … } {“desc”:”La mp” “timestamp” : …} {“desc”:”Ph one” “timestamp” : …} {“desc”:”Ou tlet” “timestamp” : …} {“desc”:”Ac me” “timestamp” : …} r-node s-node /hvac /CT /Chiller /vent /loadtree /panel /xform /outlet /spaces /floor3 /floor4 /power /mote123 /LCD

Traditional RDBMS vs StreamFS  Dealing with static data  …but stuff moves around  Must re-run query as changes happen  Distillation scope change over time  The components accounted for changes with context  Aggregate data changes in accounting w/evolution of deployment Not just on/off, but there or not there  Push vs Pull  Data pushed to external targets  User may install static or dynamic subscriptions to incoming data

Related work  Traditional energy audits  Auditing MELs  Recent LBNL study Items recorded by hand Live metering with ACme power meters integrated with the deployoment sMAP + typical RDBMS (MySQL) and non RDBMS (MongoDB) Data collection framework Taxonomy integration

Related work (2)  Streaming queries and subscriptions  Pub-sub information bus Data items self describing and include topic for consumers to subscribe to StreamFS uses pathname and item properties as topics, but also account for inter-relationship through metadata graph  Unix FS + pipes Typical hierarchical namespace with symbolic linking Pipe abstraction for subscription installation

Thanks  Questions?

Extra