Computing stuff tied to the physical world

Picking up the P1 bus

In Hardware on Nov 30, 2012 at 00:01

With the smart meter installed, I just couldn’t resist a quick readout check of the serial data of the public “P1 port”. It’s an (inverted) TTL serial signal @ 9600 baud, even parity, 7 bits with data coming out the moment you put some voltage of the “request” line.

That request line is probably nothing other than the power feed of the optocoupler inside the unit, since the output voltage more or less matches the voltage I feed it. So this could probably be operated at 3.3V as well as 5V.

A good test case for the Hameg HMO2024 scope, which has serial bus decoding built-in:

SCR39

The green bars indicate correct parity. Not only is decoding a breeze this way, the latest scope firware update also added a “Bus Table” so that you can view the decoded data as a list and even dump it to a USB stick. Here’s the first part of what came out – as a CSV file:

  "Bus Table: BUS1 (UART: CH1, L, 9600,7,E,1)"
  Frame,Mark,Start time[s],Length,Data,State
  1,,7.90800e-6,1,'/',OK
  2,,1.04791e-3,1,'X',OK
  3,,2.08791e-3,1,'M',OK
  4,,3.12791e-3,1,'X',OK
  5,,4.16791e-3,1,'5',OK
  6,,5.20791e-3,1,'X',OK
  7,,6.24791e-3,1,'M',OK
  8,,7.28791e-3,1,'X',OK
  9,,8.32791e-3,1,'A',OK
  10,,9.36791e-3,1,'B',OK
  11,,10.40791e-3,1,'C',OK
  12,,11.44791e-3,1,'E',OK
  13,,12.48791e-3,1,'0',OK
  14,,13.52791e-3,1,'0',OK
  15,,14.56791e-3,1,'0',OK
  16,,15.60791e-3,1,'0',OK
  17,,16.64791e-3,1,'4',OK
  18,,17.68791e-3,1,'6',OK
  19,,18.72791e-3,1,'0',OK
  20,,19.76791e-3,1,'9',OK
  21,,20.80791e-3,1,'9',OK
  22,,21.84791e-3,1,0x0D,OK
  23,,22.88791e-3,1,0x0A,OK
  24,,23.92791e-3,1,0x0D,OK
  25,,24.96791e-3,1,0x0A,OK
  26,,26.00791e-3,1,'0',OK
  27,,27.04791e-3,1,'-',OK

Pretty trivial to decypher, so I whipped up a Tcl script for my trusty JeeMon swiss army knife (whatever works, right?):

Screen Shot 2012 11 29 at 18 08 52

And here’s the result of one scope capture (serial numbers were altered a bit):

  /XMX5XMXABCE000046099

  0-0:96.1.1(30313337323430332020202020202020)
  1-0:1.8.1(00003.540*kWh)
  1-0:1.8.2(00011.199*kWh)
  1-0:2.8.1(00000.000*kWh)
  1-0:2.8.2(00004.667*kWh)
  0-0:96.14.0(0002)
  1-0:1.7.0(0000.35*kW)
  1-0:2.7.0(0000.00*kW)
  0-0:17.0.0(999*A)
  0-0:96.3.10(1)
  0-0:96.13.1()
  0-0:96.13.0()
  0-1:96.1.0(3131323838323030303336383037303132)
  0-1:24.1.0(03)
  0-1:24.3.0(121129160000)(00)(60)(1)(0-1:24.2.0)(m3)
  (00014.684)
  0-1:24.4.0(2)
  !

(probably took some committee years of work to come up with this sort of gibberish)

Four electricity counter totals (night/day and consumed/produced, respectively), then two actual power consumption/production levels, then the gas meter readout. Note that the meter does not know the separate consumption and production levels – it only sees the total, but it can detect whether the flow is positive or negative.

Easy stuff. Access to the values used for our electricity and gas bill at last!

PS. This will also allow comparing and calibrating the results obtained by other means: three 2000 pulse/kWh counters attached to a JeeNode and three current transformers attached to the Flukso Meter. They each measure different things, but it’s all hooked up in such a way that the total consumption or production can be calculated with each setup.

  1. Should be interesting to compare the accuracy between the two. If something is off… I guess it will tell you if you coded something wrong, and are losing packets! Or maybe the purchased meter will prove to be the issue…

    • Note that lost packets will not affect things, since I include cumulative totals. They do happen, occasionally.

  2. The Gas reading may have temperature coded in there – since the billing is meant to be based on energy consumed, the volume needs correcting by temperature. Might already be done in the meter – it is an option.

    No sign of kVA on the electricity reading? Surprising, the days of “free” domestic reactive power are numbered I suspect.

    Now that’s an idea – if the utility starts charging for reactive energy, make plenty and get a credit ;-)

  3. Note that the meter does not know the separate consumption and production levels – it only sees the total, but it can detect whether the flow is positive or negative. So no built-in option for differentiated tariffs other than day/night! There goes the ‘please do use less electricity now‘ option.

  4. @eljonco, correct. The only ‘smarts’ this meter has is bi-directional reporting. But that is with the current firmware. Note the IR pair on the front panel – probably new firmware (and certainly new parameters) can be downloaded with the Meter Reader’s magic wand.

    Load shedding on demand was meant to be a negotiation – ‘If you shed x Kw load right now for y minutes, I’ll offer you €z discount’. Big Power has twisted this into ‘shed load now and be grateful your consumption charges are so low’.

    Sigh… A missed opportunity for integrating co-operative microgeneration.

  5. Hi JC,

    Here are my thoughts on the smartmeter and P1 port. Might be of interest: http://www.maartendamen.com/tag/smartmeter/

  6. That data format is OBIS. Yes, it’s disgusting committee blobs. The bit before the colon is optional, and only being shown to you because you’ve got gas in the mix. (There’s codes for gas/electric and other types) 1- is the gas, 0-1 is the electricity (as you may have worked out.

    At least you’re getting relatively common obis ids. There’s lots of overlap and plenty of space for people to use different codes. And creative interpretation of units and decimals too.

Comments are closed.