DTE Energy Bridge python fix/reverse engineering

This could really be two entries, but I think I’ll skip the details for the first one and just skim over what I remember. It’s not like it really matters so much anymore as this hardware’s all discontinued. I may be motivated later to go back through and re-take some data but for now I’ll keep it mostly to the practical and easy to implement things.

Some time ago DTE (that’s the Detroit Edison power company) began offering the DTE Energy Bridge to consumers for free to go along with their DTE Insight app to view power consumption. It was a way to get you to install a bridge between the 802.15.4 network their smart meters use to the internet since the mesh network doesn’t carry that much information back to them. This allowed approximately 1hz sampling meaning you could see when the washer or dryer were done, when the air conditioning kicked on, lots of useful stuff. I signed up for one of these devices and got it on April 27, 2016. I know that because on my way out the door the next morning I noticed a box, took it to work, opened it in the parking lot, and dissected the device in my car (and I still have the timestamped pictures).

I wanted to investigate the serial lines…

The device I got consisted of an arm processor, a memory chip for that arm, an ethernet PHY, and an XBee PRO S2C module. I had some grand plan to reverse engineer the contents of the memory chip to figure out what the processor was doing, maybe redirect the upload url through dns redirection, maybe even just get a copy of the program that’s reading the power meter so I could figure out how to do it myself. I haven’t done any of these yet. I may never, but the possibility is still out there. The designers of this device were kind enough to run a web server on port 80 that gives you the instantaneous power use of whatever meter it’s paired to. I don’t know how they pair, if it’s done by a server once it’s online for the first time or if it’s baked in to the device before they send it. What I did manage to figure out was that the only wires hooked up to the XBee module were power, ground, tx, and rx. This device just used the XBee radio as a serial slave, which is good for future development.

What I also figured out by logging the first 24 hours of tx AND rx was that the XBee radio was using….. stock firmware! That was a bit of a relief that the commands shown in the manual were being sent along just as expected. I could see the encryption key being sent to the radio in plaintext. This is good news for anyone that wants to just eliminate this device and build their own, all you need is a microcontroller (might I suggest the esp8266) that talks serial and an XBee module and you can send the same messages that the energy bridge sends, encryption key and all. The next problem is message formatting. I didn’t do any work on this front, but there’s some packed binary message from that contains at least the current ac power draw, I don’t know anything else that might be transmitted but not shown in the DTE app.

The reason I stopped all this is that they released a new version of the energy bridge that’s supposed to be some very strange super closed source IoT portal thing. They want to charge a monthly fee (no way, man) and it now does some junk over bluetooth for some unknown reason (insert crass joke about under the table kickbacks from the bluetooth sales rep here). The messages went out that the old models would stop working and you were to dispose of them as e-waste, but they did not stop working. Sure, the DTE app infrastructure may have stopped listening, but my little box kept on reporting the power draw on the web server.

Now we move on to the practical issue I want to solve. There’s a bug in the V1 software somewhere. for no reason, sometimes it reports 0W power draw which is impossible because the box itself is powered through that meter. I know this is not a bug in the homeassistant python code because I’ve refreshed the web server and seen the 0W for myself. This is a probelm for a number of reasons. First is that the data is incorrect, we can filter the data later but writing rules is easier if you can solidly say that your house consumption was at “less than X Watts”. Second is that the graph gets harder to read always jumping down to zero. Auto ranging on the graph axes doesn’t work when the rang is artificially enlarged.

Data captured before and after my fix

The fix is rather simple. There’s already an instance in the integration that moves a decimal point by inferring where it should be, all we have to do is put another check in to see if the value is exactly zero. This is what I added:

# A workaround for a bug in the DTE energy bridge.
# The returned value can randomly be 0W. This does not happen 
# in normal situations and can be seen as an error rather than data.

if val == 0:
	_LOGGER.warning(
		'Unlikely value from DTE Energy Bridge: "%s" (%s)',
		val,
		self._name,
	)
	return

All it does is return without a value if the value is exactly zero. This is the same as if it had timed out. I tried to get this put into the homeassistant code repository but they said they wanted it in a python package and since I have no interest in doing that I’m now maintaining this alongside my homeassistant install and backporting my fix as I update. I’m a little annoyed, but not motivated to go learn a whole new thing just to help someone else, I already have a fix. If someone else wants to go do that then please do and let me know when I no longer have to maintain this fork, but until then here’s my fix for the current DTE Energy bridge integration in homeassistant.

Possibly some collaboration between my old device and someone else’s V2 might allow us to grab their encryption key and send the data to an old decommissioned V1 model. Perhaps a MITM where I read the incoming encryption key, throw it out and substitute the one sniffed from a V2, then send the message on to the XBee and the data received is then decoded by the black box arm and put on the network. That would allow you to not pay a monthly fee, get the data, and not have to decode the messages. Maybe it wouldn’t work for a number of reasons, but it’s a start. Knowing how to talk to the meters even if you don’t know what they’re saying is a start. For now my bridge sits here humming along and not being allowed to access the internet (thanks google wifi parental controls).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: