The WeMo (R) plug provides two basic capabilities: switching a load on/off, and monitoring the load's energy usage. The load switching is pretty straightforward, a standard 15 amp relay on the mains current path is connected to a GPIO line on the control board. Since the relay is, by design, isolated the control board can safely switch the load without using mains voltage.

Monitoring the load's energy usage is a more complicated affair. For this task, the WeMo(R) uses a dedicated daughter board with a solid state meter chip. Putting this on a separate board is probably motivated by space constraints and UL rules about trace width/separation for high current, high voltage lines. Removing the meter board shows a silkscreen which helpfully labels TX and RX pins (although RX is sadly not connected)

Packaging the WeMo(R) back together and attaching it to a scope shows that one of the wires on the control board harness is in fact carrying some data. The actual connection between the control board and the meter is a tricky affair. An optical isolator separates the two so the casual user would not notice the connection with a simple multimeter tone out.

Of course the scope can only get us half way there. Switching over to a logic analyzer (I use a Saleae Logic) we can try decoding the signal. There are a few standard communication protocols: UART, SPI, I2C. The silk screen suggests UART since both SPI and I2C require a clock which is noticeably absent. UART's can have a variety of settings for baud rate, bits per frame and parity but fortunately the data pops right out using a standard 9600 8N1 decoding. Unfortunately the only consistent pattern seems to be the two bytes at the beginning of each packet [0xAE 0x1E] and the packet length of 30 bytes. The rest of the fields seem consistent over time which indicates they are probably measurements, but their values are hard to decipher.

After lots of tinkering with loads of varying power levels and even directly tweaking the AIP and AVP lines I still could not make sense out the data fields. Given that there was so much data (30 bytes) this must be quite a nice chip and probably doing much more than the stock WeMo(R) app was letting on. If only the WeMo(R) came with a datasheet....

Time for some detective work. The meter chip has 16 pins and some inscrutable markings - no manufacturer logo or other easy giveaway. Searching for 16 pin power meter chips on Digikey gives plenty of results. Looking through these data sheets for UART connections and the magic number 0xAE gives a clear winner- the 78M6610+PSU. This chip has an auto reporting mode that periodically sends UART data with a header byte of 0xAE. The data format of the auto report, detailed on page 25, specifies that the second byte is the packet length. Ah ha! 0x1E is hex for 30. Excellent.

The 78M6610 is no slouch, according to the datasheet:

"An embedded 24-bit energy measurement processor (EMP) and firmware performs all the necessary computation, compensation, and data formatting for accurate, real-time reporting to the host. With integrated flash memory, the 78M6610+PSU is a completely autonomous solution capable of storing nonvolatile data such as calibration coefficients and input configuration settings."

This is quite exciting- WeMo(R) really went all out with this guy. Unfortunately their app exposes only a small fraction of this chip's real power. All the more reason to make an open source controller! I googled around to see who else might be using this chip and imagine my surprise when I came across this press release. Of course I had no luck finding this document before I did my Digikey hunt, but using the keywords 78M6610 and Belkin it pops right up. Confusingly though, it claims the WeMo(R) uses the 78M6610+LMU which doesn't seem to have an auto-reporting mode and only comes in a QFN-24 package.

Both chips use the same processing core and overall are quite similar. A very large set of registers collects data that can be queried directly or a selected subset can be sent automatically. After playing with some loads and using the datasheet as a guide, I managed to figure out 5 of the 7 data fields:

Auto Report Data Fields:
=====================
0: ???
1: ???
2: Vrms         X 1000
3: Irms         / 7.77e-6
4: Watts        X 200
5: Pavg         X 200
6: Power factor X 1000
7: Frequency    X 1000
8: kWh          X 1000

To automate the process, I wrote a simple script to that parses the packet. Data fields are 3 bytes each and the packet is signed by a simple checksum. Checkout the SmarttEE git repository for the code.

The data appears to be signed integers translatable to normal units by a scaling factor (Irms is a bit odd though...). Here's were it gets really weird though- the 78M6610+LMU is the only chip with the kWh register. So maybe Belkin has a special deal with Maxim? Maybe I missed something? If you have any ideas please let me know!

Stay tuned for more details.... (and more stuff in the git repo!)