Motivation
>A breaker-level power metering device for measuring energy on 4 different circuit lines and wirelessly outputting that energy data onto Google PowerMeter.
Useful Links
Similar Projects
- Zigbee Wireless Relay Control & Power Monitoring
- PowerBox: The Safe AC Power Meter
- edcheung.com – Power Line Monitor
The fastest, cheapest way to slow climate change is to USE LESS ENERGY. According to a recent National Geographic article, most of us could reduce the amount of energy we consume by about 25 percent. So why isn’t everyone doing this?
There is a growing group of Zigbee devices targeted at residential and commercial energy consumers that monitor, control, and automate the delivery and use of energy. The novelty of these Smart Energy (SE) compliant devices is that they can form a dynamic device network regardless of the product manufacture because they use the same SE firmware load on Zigbee devices.
Our project aim was to create a breaker-level power metering device that would sit next to the home’s main distribution panel (or subpanel) and measure the power on up to 4 different circuit lines and output the energy data to Google PowerMeter. The current is measured in a non-contact manner so that any user could safely install the current sensors. The radio devices transmitting the power data comply with the ISM 2.4 GHz frequency band standards and also implement a Zigbee defined encryption for security.
We suspect that our version of the XBee SE Power Meter would be extremely useful for landlords and small businesses looking for a low cost way of monitoring multiple buildings or renting out portions of the same home. In the past, this group has largely been delayed in becoming energy conscious because they have almost no motivation to buy high efficiency windows or appliances as the tenants pay the energy bills. Equally unmotivated are the tenants, who are frequently short term occupants, and don’t want to invest in the building either. Our system makes it easy and cheap for the commercial building owner to monitor the energy usage which helps with maintenance and is a selling point for the tenants if a public website is used.
System
Top Level Diagram
In the diagram above, we see the end-to-end top level description of the system. The process is managed with a Python program on the computer that controls the “Coordinator” XBee device and periodically provides the Google PowerMeter system with the cumulative kilowatt-hour energy readings from each of the measured circuits.
The terms “Coordinator” and “Router” refer to the specific XBee SE firmware that is loaded onto the XBee. A “Coordinator” controls how “Routers” connect to the Zigbee network among other network privileges and also may transmit, receive, or route data. A “Router” must first ask the “Coordinator” to join the Zigbee network, but after that it gains network management privileges and may transmit, receive, or route data. Hopefully it is obvious at this point that the variety of Zigbee device types and their common network privileges make for a very flexible and dynamic network.
For one measure process, the CPU sends the XBee “Coordinator” an SE formatted API frame that asks the “Router” to poll the end devices attached to it. This frame structure is not subtle as it is the backbone of the SE compliance, see the section of XBee and SE for more information. The “Router” receives this API framed command and forwards it to the “end device” that is attached to it: the MCU. The MCU must parse the API frame and return the measured power values in the same API framed structure. The power values are constantly being measured by the MCU and so the value it sends to the router is an accumulated power value for each of the circuits it’s measuring. These values are returned to the “Coordinator” and sent over serial to the Python program on the CPU which puts them to Google PowerMeter.
XBee and Smart Energy
Initializing the Devices
The purchased XBee RF modules we purchased arrived in a raw state in that they we’re not yet configured with the firmware needed to operate as different devices within an SE network.
In order to change the firmware we had to download and learn digi’s X-CTU. This software is designed to interact with the firmware files on the XBee’s and was essential in first establishing a network.
We first established the serial connection to the modules by using the AT commands over serial within X-CTU. This ‘AT’ setup is a workable sort of command line for the devices in which you can read and write the parameters using short ASCII codes. This allowed us to read the errors off the devices as we tried to establish a connection between them.
The coordinator is configured to start a network on one of the 14 channels in the default scan channels list. We don’t choose the channel, it just searches for the one with minimal conflict will occur. Once a network channel has been chosen, a modem status API frame is sent across UART and the LED will toggle at 1Hz. We ran into problems at first connecting to this established network because the Permit-joining time had the incorrect default value and was not allowing the router enough time to join. It should also be noted that the encryption link key is also set and distributed by the coordinator module.
– Router –
The router is configured to join any network that allows joining up to three times when first powered on. This is very handy for debugging in that you can rapidly test network connecting by simply power cycling the router (the coordinator is never powered down). Once a network is found, the router will request the encryption link key from the coordinator. When a router is connected to a network is sends an confirmation API frame through its UART and blinks its LED at 2Hz.
Implementing ZigBee Device Profile (ZDP)
The Zigbee Device Profile is the communication protocol over which you manage the devices in your network. In order for our system to be Zigbee Smart Energy compliant we were required to code a significant portion of the feature list in the ZDP. The challenge with implementing the ZDP in Python was correctly formatting the transmitted API frames and parsing the returned API frames on UART. We coded the parsing and formatting for the following XBee ZDP messages:
- Simple Descriptor Request
- Active Endpoints Request
- Match Descriptor Request
- Unsupported ZPD requests
A more detailed discussion of packaging and parsing the API frames follows the next section.
Zigbee Cluster Library (ZCL) Support
The Zigbee Cluster Library specification is the means by which we communicate commands to the coordinator which in turn commands the router. The library is broken up into clusters depending on the specific functionality. We implemented the Basic Cluster set (Cluster ID 0x0000) and the Simple Metering Cluster (Cluster ID 0x0702) so that we would conform the Zigbee required cluster support for a metering device. The list of general features that Zigbee requires of a metering device are as follows:
Parts List:
| Quantity | Part Description | Vendor / Part ID | Price |
|---|---|---|---|
| 1 | ECE 4760 Custom PC board | Course | $4 |
| 1 | Custom PC Board – RS232 & Max233 | Course | $8 |
| 1 | Mega644 | Course | $8 |
| 1 | DIP Socket | Course | $1 |
| 1 | Solder Board (larger) | Course | $2.50 |
| 1 | White Board | Course | $6 |
| 4 | Hall Effect Current Sensors | DeviceCraft / IS-2-80A | $6.50 |
| 2 | XBee RF ZB | Digi / XB24-Z7CIT-004 | $17 |
| TOTAL | 89.5 | ||
For more detail: XBee RF Smart Energy Compliant Power Meter Using Atmega644
