LabSense: Energy Monitoring in the Browser

Transcription

1 LabSense: Energy Monitoring in the Browser Jason Tsao NESL ABSTRACT This project involves sensing many different characteristics about a lab (i.e. ambient temperature, electricity, water, occupancy) and making the data available in a user intuitive web interface. Keywords Real-time, Website, Energy monitoring, Python, C++, C, Javascript, HTML, CSS, Zeromq, Socketio 1. INTRODUCTION Buildings currently account for 41% of total energy consumption and 73% of electricity consumption [1]. Consequently, small improvements in energy and resource management can have a large sustainability impact. Therefore we must ask the question, How do we improve our energy and resource management? In order to answer this question, we must first be able to access the current state of our energy consumption. Once we have a clear idea of our current usage, we can make further inferences about how best to reduce resource usage. Large businesses and universities are often requested to reduce power usage (especially during peak hours) and current systems dumbly shut off different buildings or sectors. These systems need more information about the different components under their control in order to more intelligently shut off power. Energy monitoring combined with other types of sensors (for instance to detect occupancy) provides this needed intelligence and can result in both reduction in energy usage and more intelligent power shut off (shutting off less important devices). This combination of sensory devices and energy monitoring should be able to not only visualize the data, but also log the data so that we can make comparisons between the current state of the system and an improved or old system. Making this information available online would make this system even better because it would provide easy access to the information anywhere in the world. This is the motivation behind LabSense, a project that streams sensor data to a web browser (real-time) and saves data to SensorSafe. The sensors/sensing devices offer insight into the current state of energy usage and allow a power manager to access different measurements about a lab such as luminance, temperature, and current. 2. System Architecture LabSense consists of eight major components: (1) Raritan Dominion PX8, a power distribution unit, (2) Veris Power Meter, (3) Zwave sensors, (4) Sensorsafe Forwarder, (5) Zeromq to socketio forwarder, (6) Django Server, (7) SensorSafe, and (8) the LabSense Website (see Figure 1). The sensors and sensing devices communicate with the SensorSafe Forwarder and the Zeromq socketio forwarder using Zeromq. Socketio is used for communication of the sensor data to the LabSense Website, while HTTP POST requests are made to Sensorsafe for storage. This paper is organized in the following manner: (1) Section 3 will talk about the different system components involved in LabSense, (2) Section 4 will talk about the different protocols that were used to communicate between the different components, (3) Section 5 will talk about the website architecture, Section 6 will talk about Future Work, and finally Section 7 will conclude the paper. Figure 1. LabSense System Architecture 3. System Components The LabSense project contains several components. Most components have their own executables that perform data retrieval and sending of data to other components. Supervisor, a system that allows monitoring and control of different processes, is used to manage the different executables. This system allows a power admin/manager to see at any time whether any processes have failed. Supervisor restarts processes if they fail and log data for each executable. There are several options available for controlling the executables. Supervisor has a web interface that enables admins to turn on/off the different executables, look at logs, and diagnose problems. Now, I will talk about the different components of the system. 3.1 Raritan The Raritan Dominion PX8 power distribution unit was used to monitor the energy usage of different switches and servers in the back room of NESL (see Figure 2). The Raritan had a wide variety of different appliances/devices plugged into it to see different power profiles. For each outlet, LabSense monitors the current in milliamps, the voltage in millivolts, the active power in Watts, the apparent power in volt-amps, and the power factor as a

2 percentage. The variables are read from the Raritan using SNMP (Simple Network Management Protocol). The code is written in python using a pysnmp library. The data retrieval is done every minute and can be configured as a user sees fit by changing the sample interval variable. Figure 2. Raritan Electric Socket Mappings 3.2 Veris The Veris E30 is a panel or branch-level monitoring instrument that can measure different electrical aspects of a lab or room at the mains or brain level [2]. Veris provides data connectivity and is the entry point for LabSense to get its readings. To measure electrical characteristics, the Veris uses several current transformers. Veris provides data to LabSense by mapping the electrical characteristics to several registers, which it then exposes to LabSense through the Modbus RTU protocol over the RS485 serial bus. The Modbus RTU protocol is provided over a TCP/IP connection. LabSense performs register-read and register-write request messages to obtain the current (A), power (kw), and power factor (%) of the different electric sockets in the lab. The code to interface with the registers is written in C and is adapted from [2] to keep a persistent connection and store data. The C code basically reads the characteristics, stores into arrays, and sends batched messages over Zeromq to the forwarders. The mappings of the electric sockets to the registers on the Veris are given in Figure 3. To find these mappings, a high power light was plugged into each outlet, while the current readings were logged. I then looked at the changes in readings to see what outlets mapped to what register. The Veris provides several other variables, which can later be included in the LabSense system. Veris provides a great insight into the current lab characteristics and provides the main energy statistics of LabSense. Figure 3. NESL Electric Socket to Veris Register Mapping 3.3 Zwave Zwave is a wireless communication protocol created mainly for home automation, particularly for remote controlling applications in homes. The technology embeds a low-power RF radio into different types of sensors such as sensors that detect light or motion [3]. The main reasons for choosing Zwave is that the protocol is wireless and can easily be deployed to different laboratories and rooms of a building without dealing with cables. Zwave also was used because has a good selection of sensors developed for it. In LabSense, there four Zwave components were utilized: (1) Aeon Labs Door and Window Sensor, (2) Homeseer HSM-100 Multi-Sensor, (3) Aeon Labs SmartSwitch, and (4) Aeon Labs Z-stick Aeon Labs Door and Window Sensor The Aeon Labs Door and Window Sensor is a magnetic door/window sensor. The sensor is essentially a binary switch specifying 255 when a door or window is open and 0 when the door or window is closed. LabSense reads the data on an eventdriven basis (meaning when the door is open or closed, the data is sent). The data is not constantly polled to save on battery life. Two Aeon Labs sensors are mounted on the entrances to NESL (see Figure 4) Homeseer HSM-100 Multi-Sensor The Homeseer HSM-100 Multi-Sensor is a Zwave device that is primarily used as a motion sensor, but also provides temperature and light readings. The device provides many different knobs for configuration such as a timeout specifying how often to wake up and send data, and the sensitivity of the motion sensor. The sensitivity can be adjusted so that only weak or only strong changes in motion are detected, as well as somewhere in the middle. The unit has a range of 30 feet with a sensor angle of 90 degrees. The luminance readings are provided as a percentage and the temperature sensor are provided in Fahrenheit, with a 0.2 degree resolution. The HSM-100 provides several measurements, but unfortunately the battery must be replaced about once a month (based on my usage). If the querying mechanisms and settings are set less aggressively, the sensors can actually last for up to a year. Unfortunately, due to the nature of a real-time system, data is required pretty often and thus the battery does not last very long. Six HSM-100 sensors are mounted in NESL (see Figure 4) to cover a representable portion of the lab. They are mounted seven feet from the ground, which is the recommended height for optimal sensing Aeon Labs SmartSwitch The Aeon Labs SmartSwitch measures the energy usage of any device that is plugged into it. The device reports energy in kilowatt-hours and power in watts. The SmartSwitch allows LabSense to turn on or off whatever is connected to it. This is a very useful feature because when energy companies request companies and universities to reduce power usage, these SmartSwitches can be used to control what gets shutoff in a much more fine-grain manner than completely shutting down parts of a building or rooms. Currently, the SmartSwitch is mounted to the printer in NESL (see Figure 4) so that different power and energy readings can be observed as different printing jobs are sent to the printer Aeon Labs Z-stick The Aeon Labs Z-stick is a Zwave USB dongle that enables a PC to read the data sent wireless over Zwave. The Z-stick exposes a Serial API through the USB port, which is read using a Guruplug Plug Computer. The Aeon Labs Z-stick is paired with all of the other devices before receiving data from each device. The data is read using a C++ program and the Open-Zwave library. This open-source library provides a way to read the data from the devices in the form of notifications. The library also provides mechanisms for specifying the different configuration options for

3 each of the sensors in the network. I used this library to specify different wake up times, different energy values to return, and ways to deal with each sensor. The Z-stick receives data from the door sensors, the HSM-100 multi-sensors, and the SmartSwitch (see Figure 4). From my tests, I didn t see any dropped packets. The fast transmission speed provides a great base for the real-time aspect of the LabSense project. Figure 4. Placement of Zwave Components 4. Communication From the very nature of a real-time system, communication is very important. Therefore, I made sure to utilize efficient communication protocols and libraries that could provide a close to instant visualization of data as it comes in from the different sensors. 4.1 Sensor/Sensing Device to Forwarder Communication To communicate between the different sensors and sensing devices, I used Zeromq, a socket library that acts as a concurrency framework. Zeromq was created in C, but has multiple language bindings for other languages. For the SensorSafe Forwarder and the Zeromq-to-Socketio forwarder, I used python to receive data from the sensors. On the sending side, I used Zeromq in python for Raritan, C for Veris, and C++ for Zwave. The API for Zeromq provides a send and receive interface. I made use of the publishsubscribe pattern for Zeromq in which I could provide my different sensor output on different channels and the receiving side can choose what channels to listen on. The system is very extensible and allows other people to access to the data by listening on different TCP ports (if they have access to the computer). Both the SensorSafe Forwarder and Zeromq-to- Socketio server listen on the same channels to retrieve the information. I sent the data with the following protocol: [Channel]_[Measurement]_[Sensor Number] [Sensor Values ]. This provided an easily extensible and broad enough definition to generalize to all the different types of sensors. I originally considered using JSON to encode the data, but felt that the overhead was not worth it (for instance to manually label each of those values with a key with provide extra strings). Moreover, the languages didn t all natively support JSON. 4.2 Forwarder to Website Communication There are two websites that the data is sent to. The data is sent to SensorSafe with a HTTP POST request and to the LabSense Website using Socketio SensorSafe Forwarding To send data to Sensorsafe, a standard HTTP POST request was used (this is the standard way to interface with SensorSafe). I implemented three different policies for how the data is sent to SensorSafe. The first policy is simply sending the HTTP POST request as soon as the data comes in from the sensors. The second policy is uses a given interval to only send the data every time the interval has passed. The third policy sends the event-driven sensor data immediately, while running by the second policy s interval for any non-event-driven sensor data. The event-driven sensor data for LabSense corresponded to the detection of door open/close events from the Aeon Labs Door Sensor and Motion detection from the HSM-100 Multisensor. The rest of the sensors are considered non-event-driven and are sent according to the interval given. The data is never deleted until the data has been successfully sent to SensorSafe to make sure data is never lost LabSense Forwarding During the development of LabSense, I needed a way to push data down from the server to the client whenever the server received data from the sensors. To send data to the LabSense website, I used socketio, a library that makes real-time applications possible in every browser and mobile device, blurring the difference between the different transport mechanisms [4]. There are a multitude of different protocols that can push data from the server to the client. Some are faster than others and some are only supported by a few browsers. To get around this problem, socketio selects the most capable transport at runtime. Socketio has one API for several different transportation protocols including Websockets, Adobe Flash Socket, Ajax long polling, Ajax multipart streaming, Forever iframe, and JSONP Polling. Websockets offer a full duplex, bidirectional connection over TCP and is the best option in terms of speed. However, several browsers do not support Websockets, so socketio will automatically fall back to the other protocols named. AJAX long polling and most of the other protocols (except Websockets) operate in this manner: (1) The client sends a request to the server (2) The server sends data to client whenever it has data to send. (3) The client receives the data and immediately initiates another request to the server and the process starts over again. As you can see this less ideal than Websockets, which can send data back and forth at any time, but Websockets is part of the HTML5 standard, which is still being implemented by different browsers. Socketio enables LabSense to work on virtually any browser (PC or mobile). Also, as better technologies are adopted (namely Websockets), LabSense will be able to automatically benefit from the changes. The Zeromq-to-socketio forwarder takes the Zeromq data and creates a JSON message that includes the data with some metadata such as channel and timestamp. The argument for JSON here over previously (in zeromq), is that JSON is natively supported in javascript, whereas the other languages do not necessarily support JSON (i.e. C/C++). This

4 forwarder also includes a Sqlite database for caching the data. The point of caching the data is so that the graphs shown on the LabSense website can have previous data filled in, rather than just showing the very latest data. The Sqlite database deletes entries when results of its queries exceed a given limit. It s important to note that if this limit is set too high, socketio will need to send an immense amount of data to the website. The website may therefore get very slow and laggy and thus the limit should not be set too high. I m currently using 20 and the data is still fairly large. I originally considered querying SensorSafe for the historical data instead of keeping a cache; however, accessing the data from SensorSafe (even with limits on time) took an unreasonable amount of time. Therefore, querying SensorSafe for prepopulating the graphs was out of the question. The current systems works well, but if more historical data is wanted in the future, another approach should be taken. I will talk about ideas in the future works section. The Zeromq-to-socketio forwarder is served by Tornado, an event-driven web server. The reason why this was separate from Django was that there is a lot of data being sent to the website, and sending data with Django on top of serving the files would provide a very laggy experience. With a separate Tornado server, the website can still be working even if the socketio connection fails. Moreover, socketio was originally created for node.js, an event-driven server-side javascript web framework, so Tornado s event-driven property makes sense with socketio s architecture. The nature of sending and receiving data also, by its nature, is very event-driven. For instance, the LabSense website updates the table and graphs upon receiving data from the server. 5. Website Architecture The LabSense website has several different components. On the backend, I used Django and on the frontend, I used Backbone, Bootstrap, and HighCharts. 5.1 Backend: Django Django is used to serve the website and is extensively used for the website development. I made extensive use of the Model-View- Controller (MVC) architecture of Django, which separates the representation of information from the user s interaction with it [5]. The main idea behind a MVC framework is to represent data and rules in models. Then controllers use the models and create operations to be performed on the website. The views are the actual output representation of the data. For LabSense, three models were created: Channel, Measurement, and SensorValue. The Channel model includes information about a channel (Raritan, Veris, or Zwave), the name, the slug (url version of the name), and the number of sensors. Within each channel, there are several measurements (i.e. Raritan has Current, Voltage, etc), and within each measurement there are several sensor values. Controllers instructs the views on how to display the data. For instance, the sidebar on the LabSense website was created by iterating through all the Channels and their associated Measurement models. Django s templating interface is then used to direct the view to the correct data. 5.2 Frontend: Backbone, Bootstrap, and Highcharts Backbone.js is a frontend MVC framework that gives structure to web applications. I did not need to use most of the features due to the MVC framework already provided by Django, but I did use Backbone s binding and event-triggering interface. I used Backbone to automatically call on functions to update the graph and the table whenever data is received over socketio. To style and layout LabSense, I used Bootstrap, a collection of different HTML, CSS, and Javascript UI components. I used their 12-column grid to layout the website into a sidebar on the left and content on the right. A greater feature of Bootstrap is that it has a responsive design, which means that the website scales to different resolutions and screen sizes. This is very important because it enables the website to be viewed on many different monitors and mobile devices such as ipads, iphones, and tablets. Bootstrap also provided CSS that makes the sidebar and tables look visually appealing. To plot the data coming from the server, I used Highcharts, A charting library written in Javascript. Highcharts provides an intuitive JSON interface to configure the options for the graphs. The interface provides a mechanism to chart several different graphs at the same time, which can be utilized in the future to graph multiple sensor data at the same time. The graphs automatically add points to the graph as the data is received over socketio. 6. Future Work The current LabSense project provides a good starting point for making inferences based on the current state of a lab. Algorithms can be developed to use the current data to predict future energy usage. Moreover, LabSense can be used to intelligently scale power down when energy companies require it. A rule based system can be developed that lets a user specify rules the sensors must abide by in order to reduce energy usage. LabSense can be further improved to include more history. The main issue behind sending too much history data is that such a large amount of data can provide a very laggy experience on the website. A solution maybe to use shared database to separate data across computers and enable much faster querying. The database is currently running on the Guruplug, which is not meant to serve high volumes of data. Therefore, forwarding the data to a highend server may be a better option as well. The SensorSafe Forwarder and Tornado server (Zeromq-tosocketio forwarder) can be combined into one entity so that the data being sent to both are exactly the same. Moreover, both forwarders can benefit from the routing policies discussed earlier, and combining the two will mean less messages to send in the Guruplug. 7. Conclusion LabSense is a real-time sensing platform that provides important aspects about a lab or room such as temperature, light, energy, and power. With this platform, one can make inferences about power consumption, and intelligently manage power. The LabSense interface is intuitive and enables a user to view graphs of any channel, measurement, and sensor simply by clicking on the location in the table. The navigation of the website simply involves clicking on the different links in the sidebar. The overall look of LabSense is fairly clean and visually appealing. With this platform, future work can intelligently reduce power usage and properly assess new power improvement policies. 8. ACKNOWLEDGMENTS My thanks to Haksoo Choi for helping with interfacing the code with SensorSafe and Tianji Wu for helping with mapping out the electric socket mappings to their Veris counterparts.

5 9. REFERENCES [1] Srivastava, Lecture 10 [2] Jeong, J Application Protocol for Veris E30 Panelboard Monitoring System. University of California, Berkeley. [3] [4] [5]