Tag: powercost

Log your electricity consumption with Powermon433

NB: this is in the  early stages of development, but does work. It’s by no means a plug-and-play solution. You’re going to have to do some coding, and perhaps some soldering. Undaunted? Read on …

I really like the Blue Line Innovations PowerCost Monitorâ„¢ (aka the Black & Decker Power Monitor EM100B). I bought one long before the OPA started to give them away free to Ontario households as part of their peaksaver PLUS program. It’s a little device that clamps to your hydro meter and sends instantaneous power readings to a display.

PowerMonitor-displays
Power Monitor displays — Black & Decker on the left, Blueline on the right

Wouldn’t it be so much better if you could log and analyze these data? So a day’s power consumption might graph to something like this:

PowerMonitor-20140929Yup, this is my real electricity consumption, as logged from the PowerCost Monitor. You can see the fridge cycling on and off, and I think the big mid-day spike was either the AC or the dryer; someone was home on that Monday. The rather blocky green line is Toronto Hydro’s hourly smart meter data. It really hasn’t got the resolution to show really detailed power use.

That spike at 06:30; what’s that? Let’s take a look:

PowerMonitor-20140929-kettleThat’s me boiling the kettle. You can see that the time resolution is better than a minute, and the power is to the watt. Mmm, coffee …

All of this is recorded using a simple Arduino-based solution, originally cooked up by Bryan Mayland. I’ve forked his code and added some instructions: scruss/Powermon433. Here’s the rig I’ve been using to log data over a USB serial link:

Arduino FIO compatible + RFM69W board + FTDI serial
Arduino FIO compatible + RFM69W board + FTDI serial

That’s a particularly ugly rig, due to the limitations of the 3.3 V receiver board I was using. There are other options that work with more normal Arduino boards up on github.

Here’s a sample of the data I’m logging, including the kettle incident:

Datetime Elapsed_s Energy_Wh Power_W Temp_C
2014-09-29T06:27:44 23241.7 25876 289 15
2014-09-29T06:28:16 23273.6 25876 290 15
2014-09-29T06:28:48 23305.5 25876 291 15
2014-09-29T06:29:20 23337.4 25892 294 15
2014-09-29T06:29:52 23369.2 25892 286 15
2014-09-29T06:30:24 23401.1 25892 277 15
2014-09-29T06:30:56 23433.0 25892 357 15
2014-09-29T06:31:28 23464.9 25892 1844 15
2014-09-29T06:32:00 23496.8 25892 1836 15
2014-09-29T06:32:31 23528.5 25952 1829 15
2014-09-29T06:33:03 23560.2 25952 1818 15
2014-09-29T06:33:35 23592.1 25952 1836 15
2014-09-29T06:34:07 23624.0 25952 1836 15
2014-09-29T06:34:39 23655.8 25952 1836 15
2014-09-29T06:35:11 23687.7 25952 1848 15
2014-09-29T06:35:43 23719.6 26048 1832 15
2014-09-29T06:36:15 23751.5 26048 2000 15
2014-09-29T06:36:46 23783.4 26048 2000 15
2014-09-29T06:37:18 23815.2 26048 2000 15
2014-09-29T06:37:50 23846.9 26048 368 15

You’ll see that I’m recording:

  • a system timestamp
  • the elapsed logging time, from the Arduino’s clock
  • instantaneous meter readings in watt-hours. Note that not every row has an update
  • the average power since the last record. The product of this and the time between records adds up to the energy consumption
  • the outside temperature in °C. This is not very accurate (in full sun it over-reads vastly) but better than nothing.

Compare that to the smart meter data:

DateTime Hour KwhUsage Cost Rate
2014-09-29 05:00:00 5 0.29 $0.02 $0.075
2014-09-29 06:00:00 6 0.31 $0.02 $0.075
2014-09-29 07:00:00 7 0.59 $0.04 $0.075

Not much data there, is there? Certainly not enough resolution to tell if a kettle has been running.

Even though this interface is homebrew and cheap, it is accurate. Here’s how four days of continuous readings stack up against Toronto Hydro’s meter:

  Power Monitor ndToronto Hydro Smart Meter
Day First Reading / Wh Last Reading / Wh Total Consumption / kWh No of readings Daily Total / kWh No of readings
2014-09-29 23896 43668 19.772 2711 19.77 24
2014-09-30 43668 52500 8.832 2710 8.82 24
2014-10-01 52500 68004 15.504 2711 15.51 24
2014-10-02 68004 81996 13.992 2712 13.99 24

The difference looks to me like aliasing; THES’s reporting is much more granular.

I’m going to develop this further to turn it into an easy (or at least, easier) to use logging platform. It’s taken us a few years to get here, but there’s nothing quite like a project finally working!

Blueline / Black & Decker Power Monitor RF Packets

Update 2014-10-02: I’ve forked Bryan’s Arduino code and added some instructions: scruss/Powermon433 (though use Bryan’s, srsly)

Update 2014-08-19: Bryan Mayland has decoded the data on Arduino! More details here: CapnBry/Powermon433

Given that I first started thinking about reverse-engineering the Blueline Powercost Monitor‘s data stream in September 2010, I hardly win any awards for rapid development. Here’s what I know so far about the device and its transmissions:

  • The Blueline unit and the (now discontinued) Black & Decker Power Monitor (EM100B) appear to be functionally identical. Both transmit data using simple ASK/OOK at 433.92 MHz in the ISM band.
  • It is, however, completely different from the Norgo NGE101 meter, dammit.
  • The display unit is made by Hideki Electronic Limited, who make many small weather stations and wireless displays. [Pictures of the display circuit boards]
    Inside a Black & Decker Power Meter
  • The transmitter unit was designed by Intectus in Ottawa for Blueline. It uses a TI MSP430 µcontroller. [Transmitter board picture]
    Black & Decker Power Monitor: Meter Transmitter board
  • The transmitter can be triggered by simulating a power meter if you flash a 940 nm IR Emitter LED for 50 ms into its sensor. 1× 50 ms flash represents 1 Wh of power consumed. A pulse frequency of 1 Hz represents 3.6 kW consumption.
    Arduino-based domestic power meter simulator
  • The transmitter sends a bundle of three (seemingly) identical packets every 31.8 seconds. These appear to contain consumption data, as the display updates approximately every 32 seconds.
    a data packet bundle
  • A series of contiguous packets, recorded as audio using a simple circuit described by the Protocol Analyzer project: audio201311182215-silenced (FLAC; please note that interstitial silences have been blanked to reduce file size).
  • Temperature packets may be sent separately from power, as the display updates temperature much more slowly than power use.
  • Power packets only appear to contain use data (along with a transmitter ID). If the sensor receives an absolutely constant input, the packets transmitted 32 s apart can be identical.
    powermeter-203453vs203525
  • The packets appear to be Manchester-encoded.

Some rough notes on mark/space timing (all times in µs):

Mark : Mean    529.4 Min    499.0 Max    590.0 StdDev:   15.03 
Space: Mean    694.5 Min    385.0 Max   1474.0 StdDev:  281.57

Mark/space times, by frequency (all times in µs):

MARK
====

          µS
Rank     Value   Count
-------- ------- -----
     1         522  498
     2         544  206
     3         567   32
     4         499   32
     5         590    8

SPACE
=====

          µS
Rank     Value   Count
-------- ------- -----
     1         476  279
     2         975  223
     3         454   99
     4         952   65
     5         431   26
     6        1474   22
     7         408   21
     8         499   17
     9         998   12
    10      199000    8
    11         385    2
    12        1451    2

More later, including raw packet data.

Thanks to Randy Simons and Bryan Mayland for the recent help. Thanks too to Brett “Wiring” Hagman for asking just why I was trying to do this …