Energy Monitoring 101: Open Standards

In almost every architectural project we undertake at LMN, we urge the client to seriously consider sub-metering and energy monitoring.  Though far too often fodder for the Value-Engineering (VE) chopping block, monitoring resources like gas, water, steam and electricity is the first and fundamental step in understanding the patterns of use (and abuse) of natural resources in buildings.  Sub-metering and energy monitoring allow owners, maintenance managers, and occupants to better understand how and where they are burning kWs, kBTUs, gallons, etc.  Armed with that information, you can start to make the decisions that lead to energy savings, quickly paying for the upfront cost of the monitoring system itself.  So that’s all well and good.  Most people know all about that.  After years of recommending this to our clients, we decided to “eat our own dog food,” as the saying goes; we decided to bite the bullet and install our own Energy Monitoring Units (EMUs) in our offices.

We have three major goals with this project: First – and key to why we went about this the way we did – we wanted to understand the underlying costs, infrastructure changes, and digital tools necessary for proper energy monitoring.  The first goal will also have the added benefit of allowing us to tinker with our setup as much as we like…something you may have noticed (if you read this blog regularly) that we enjoy doing. Second, we want to understand our current usage and gather a baseline before we make any changes to our behavior.  Finally, we want to quantify our progress as we begin to take Energy Conservation Measures (ECMs) – a fancy way of saying: “forming better habits”.   In this post, we’ll address the first two goals directly and come back to the third goal (ECMs) in a future post…

First, the hardware.  We shopped around a bit for electrical Energy Monitoring Units.   From the start, we were looking for an EMU that would allow us to learn as much about the process of monitoring as we could.   There are many commercial-grade units available on the market, but most are very expensive and worse: some require purchasing additional software (sometimes through subscription) just to view the data the EMUs record.  With these systems, there’s the considerable upfront cost for the equipment and installation, plus – to add insult to injury – the cost of the software to boot.  What we wanted was something purpose built, interoperable, and open.  After some shopping, we found the OptoEMUOpto22‘s open standards philosophy appealed to us: all their systems run on non-proprietary communication standards like Ethernet and IP.  This means that one could integrate their EMUs into an existing monitoring system, purchase a subscription to a data-logging service (such as Pulse Energy), or roll your own system at any scale you want.  We chose the latter, without precluding the option of scaling it up.  (Baby steps.  Baby steps).  Our office occupies two floors and has four quadrants fed by four electrical panels that roughly correspond to the quadrants (over the course of 30+ years in the building, there might be some cross wiring…but we’ll find out soon enough).  We decided to test out our proposed system on one quadrant of the office to make sure that we had all the software and hardware setup before we scaled the system up to the rest of the office.  So we bought one of the Opto22 EMUs and had a professional electrician install it in our electrical room.

We called up Opto22 and explained our electrical setup and they recommended starting with a single EMU (shown above left) and three current transformers (CTs).  Out of the box, the OptoEMU is straightforward.  The installation instructions were easy to follow so we went ahead and had our electrician install one EMU in our quadrant (thanks to Tim and Josh of North Star Electric for doing a quick and professional job of installing the EMUs and CTs.)  Once installed, we plugged the EMU into our network backbone and assigned it a static IP-address.  At that point, the EMU was acting a lot like your typical wireless router: you can use any web-browser to access the firmware on the device to configure its settings.  All we needed were the correct current ratios from the electrician.  Just a couple of fields and you’re up and running.  (The browser configuration tool is also where you can setup your data-logging service if you choose to use a third-party such as Pulse).  Rather than use a third-party logging service, we decided to do this ourselves.  This will take a bit of explaining…

Second, the software.  We downloaded the OptoEMU Sensor .NET Toolkit from Opto22’s website.  We used the toolkit to write our own custom polling and logging software that runs on a dedicated machine on our network.  The application polls each of the EMUs once per minute (even though the OptoEMUs can sample at a much faster rate) and records the current kW value and a time-stamp to a SQL database running on the same computer.  This monitoring software also handles the e-mail digest system (see below).  Once we had tested this setup with one EMU, scaling it to four EMUs was very easy.  The downside of this approach is that it requires a dedicated computer on the network to handle the logging.  However, this computer serves double-duty as the Database and the Webserver.  Once all the software was up and running, we were confident enough to purchase the remaining three OptoEMUs and monitor the rest of the office.

The data logging continues, ad infinitum, but each morning – at 10:10 am – the software sends an e-mail to LMN employees with the averages from the previous day.  The e-mail separates out averages for the day and for the night.  As we start to better understand our consumption, we plan to set up alerts for unusual demands or steep trends.  The e-mail is useful, but nowhere near as useful as the interactive chart we have setup to view the data…

The interactive chart allows any user to track variable time-scales (from one minute to one year) broken out by quadrant.  The user can highlight any point in the chart and get the kW reading at that minute.  The embeddable chart is a mash-up of html, pHp, jQuery and the Google Chart Tools API.  Before assembling this mix, we looked at Pachube, Pulse Energy, and Wattvision.  All three had their advantages and disadvantages, but none was exactly what we wanted.  In short: we just wanted to do this ourselves and we didn’t think it would be that difficult.  Even though Google had “retired” PowerMeter, they had left intact the graphing API that they used to construct all their various data visualization systems…from finance to web analytics.  The only piece that was a bit of a challenge was the Annotation feature…

Users can annotate the chart much like a stock-ticker records historical events relevant to spikes or troughs in the data.  A button at the bottom of the graph brings up a calendar (we would have liked this to be a mouse-click on the graph itself, but this proved difficult to do with the ChartTools) and a text-field.  Energy Flow AnnotationThe viewer can then enter in some information (a guess of end-use, a significant event, etc.) that is viewable to anyone who checks the graph.  We are using this feature to figure out which plug-loads are responsible for specific spikes…we also think it will be a great feature for recording intentional ECMs that we will implement in the future.

All four EMUs have been up and running for about a month now.  What are we learning?  As you can see from the chart above, our 5 West quadrant consumes considerably more energy compared to the other three quadrants.  This is because 5W is the home of our servers.  We know that the plotters and printers could probably go into sleep mode earlier in the evening than they do now.  We know that lights are responsible for a large chunk of our consumption.  However, all of this is low-hanging fruit.  What we are focused on now is collecting baseline data of our typical behavior so that we can better assess the effectiveness of future conservation measures.  We’ve learned that energy monitoring doesn’t have to be overly expensive or complex – that you can right-size a solution to an organization of any scale.  We are also learning that it’s difficult to resist the urge to make changes right away, especially when we have such high-resolution data at our fingertips.

What next?  We plan to continue collecting baseline data as long as we can (how long is up for debate within the office).  We plan to embed the interactive graph into our intranet.  We also plan to use our experience to get more monitoring and sub-metering into our built projects.  We plan to start playing around with more interesting ways to interact and consume near real-time data – perhaps hooking up the feed to Arduino to change the color of ambient lighting relative to consumption?  Maybe triggering an air-horn hidden near our SysAdmin’s desk if the servers are out-of-control energy hogs?  (Just kidding Chad).  Whatever we end up doing, we plan to use this data to change our habits and consume energy in a smarter way.

We’ll return to the EMUs in a future post and let you know how things are going…


  • Ramprasad

    GMR Group has its corporate office in Bangalore in India. I am impressed by this device and would like to know if you have an Indian agent to speak to us and conduct a feasibility study in our office

    • dbelcher


      Feel free to contact Opto22 directly…they are quite helpful. For larger office/campus portfolios, you’ll probably want to check out Pulse Energy as well.

  • Arun Sinha

    Any update? Curious to see if the data has revealed any other interesting things…

    • scrawford

      At the moment we’re working on integrating the charts into the interface of the firm intranet. After that we’ll be waging energy wars between sections of the office. Those sitting next to the server will likely need to power their computers with exercise bikes if they want to be competitive.

  • Arun Sinha

    Thanks for the update. Exciting!