Reverse engineer smart meter data packets (Part I)

I received an Energy Bridge from my electric utility, DTE.  DTE has a great smartphone app but I wanted a way to intercept the data from the Energy Bridge to monitor the real-time data without the smartphone.

I had previously opened up the Energy Bridge and found an XBee SMT board.  I assumed the XBee was communicating to the smart meter and gating the data to the ethernet connection.

As a first step to intercept smart meter data, I put a shared internet connection between the Energy Bridge and the Internet and recorded TCP packets using Wireshark. The ethernet route I used did not allow the Energy Bridge to connect to the Internet.  Although I could see packets to/from relaypilot.vectorform.com 208.81.180.78, I could not be sure the packets were reporting good data from the smart meter.  I have some ideas how to improve this but they will wait for Part II.

 

Since the TCP packet sniffing turned out to be slower than I had hoped, I opened up the Energy Bridge again to poke around to see if I could tap in to the serial data between the XBee board and the microprocessor that was talking to the Internet.  First, I found the schematic of the XBee board online and looked for the DOUT and DIN pins, that are pins 3 and 4.

Those pins are right next to the tricolor LED and they have traces running from them.  So, it looks like they are connected to something.

So, I added a couple of wire taps to pins 3, 4, and 13 for ground.

 

I measured the signals with an oscilloscope and confirmed that it looks like serial data should look.

I looked at the shortest pulse duration at a given state to determine the baud rate.  The shortest pulse was ~8.75us wide.  I calculated 1 bit / (8.75E-6 sec) = 114285.  That is close enough to 115200 bit/s or 115200 baud.

Once I knew the baud rate, I hooked up the wire leads to an Arduino and wrote a little script to read the data from the XBee Pro and transmit them to the PC.  I could see 8 bits in between the start bits and then assumed no parity and 1 stop bit.

The first few bytes of the data packet in hex format looked like

The 7E, 0, 7, and 8B were constant.

The 18 is a counter running from 00 to FF incrementing by 1 in each packet.

The five 0s were constant.

The 5E looks like a counter running from FF to 00.  It goes down by one in each packet.

I also manually decoded a few bytes from the oscilloscope traces to make sure the bitbang serial in the Arduino was working correctly.

The full packet is about 43 bytes long.

I was not entirely successful in intercepting and decoding the smart meter data yet but I can see the consumption data in the 43 bytes.  It moves in a similar way as the real-time data in the smartphone app.

In Part II I will make a data logger to look at the packets over time and hopefully correlate the serial data with the TCP packets.

Stay tuned!