Current Cost Power Usage Monitor (Going in the backdoor with Software Defined Radio)

As you have probably guessed from my previous blog posts I am slowly pimping (or in the words of the misses, making a mess) my house with a variety of Internet of Things devices such as Phillips Hue, various sensors and so on. After discussing IoT devices with my work colleague the other day he showed me screenshots his fancy power monitoring solution and gave me a link to the guys who make the device he was using a “Current Cost”, so I promptly ordered a refurbished unit from the Current Cost shop on eBay. I went for the ENVI, a slightly older model but at the bargain price of £20 including delivery.

Today the ENVI arrived and I was eager to get it up and running. Inside the box is a CT clamp with an attached battery operated box, the display base unit and a power adapter for powering the base unit. The base unit has USB serial support for getting an XML feed from the device, however I was curious to see if I could get the power readings without the USB cable as it uses a custom connector and the only cables I could find are selling for £12 on eBay. According to the compliance documentation for the product the CT clamp unit transmits over 433mhz, sounds like an SDR job to me. Installation was easy I attached the CT clamp on the positive inlet cable in the meter cupboard after the meter and main supply fuse, paired it up to the display unit using the included instructions and within a minute I had a frequently updating display of the current power draw in my house.

Next lets see if we can intercept some messages from the CT Clamp to the display unit using the SDR. I used my trusty NooElec NESDR Mini 2+ with the supplied out of the box antenna for the job. I knew from the Current Cost documentation that the display updated every 6 seconds, so lets have a look around the 433mhz frequency for something with a 6 second interval. Here on the waterfall at 433.92mhz we see these lines which match up with every 6 seconds ish with a small red segment which we can assume is the packet from the CT clamp specially as the display updates each time one of these packets appears on the waterfall.

Now we have found the assumed frequency lets try passing it to rtl_433 on the off chance that someone has already reverse engineered / made a decoder in rtl_433 for the Current Cost devices. First I had to boot up my Linux VM and pass the RTL USB device through to the VM as I have never managed to get any librtlsdr stuff to compile on my Mac. I then installed rtl_433 as follows, you’ll need cmake, gcc and librtlsdr-dev etc installed prior to compiling rtl_433.

git clone https://github.com/merbanan/rtl_433.git
cd rtl_433
mkdir build
cd build
cmake ../
make
sudo make install

Now, time to run rtl_433 and see if we get any data.

rputt@rtl-sdr:~$ rtl_433 -f 433920000
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Exact sample rate is: 250000.000414 Hz
Sample rate set to 250000.
Bit detection level set to 0 (Auto).
Tuner gain set to Auto.
Reading samples in async mode...
Tuned to 433920000 Hz.
2017-06-14 18:37:25 :	CurrentCost TX
	Device Id:	 1636
	Power 0:	 363 W
	Power 1:	 0 W
	Power 2:	 0 W
2017-06-14 18:37:32 :	CurrentCost TX
	Device Id:	 1636
	Power 0:	 373 W
	Power 1:	 0 W
	Power 2:	 0 W
2017-06-14 18:37:37 :	CurrentCost TX
	Device Id:	 1636
	Power 0:	 375 W
	Power 1:	 0 W
	Power 2:	 0 W
2017-06-14 18:37:43 :	CurrentCost TX
	Device Id:	 1636
	Power 0:	 376 W
	Power 1:	 0 W
	Power 2:	 0 W

Seems to have the necessary decoding stuff implement, does the job great without no further configuration. Interestingly even when unplugging the paired base station the CT clamp unit appears to keep sending out readings. I guess the pairing is very simplistic where the base station just remembers the clamp’s Device Id and listens out only for packets from that clamp, great I can unplug the base station and put it back in the box… Next steps to write a simple Python wrapper around rtl_433 to submit the power consumption metrics back to my sensors API.

Leave a Reply

Your email address will not be published. Required fields are marked *