Dissection of a P1 telegram

We're going to analyze the content of this telegram we captured. Below is the example from previous post with annotation. The format is fully described in Dutch Smart Meter Requirements (DSMR) 3.0, an open standardized protocol.

/KMP5 KA6U001660000000	Telegram begin-marker + manufacturer + serial number
0-0:96.1.1(204B413655303031363630000000000000	Serial number in hex
1-0:1.8.1(01964.939*kWh)	+T1: Energy input, low tariff (kWh)
1-0:1.8.2(01006.545*kWh)	+T2: Energy input, normal tariff (kWh)
1-0:2.8.1(00124.673*kWh)	-T3: Energy output, low tariff (kWh)
1-0:2.8.2(01006.545*kWh)	-T4: Energy output, normal tariff (kWh)
0-0:96.14.0(0001)	Current tariff (1=low, 2=normal)
1-0:1.7.0(0000.45*kW)	Actual power input (kW)
1-0:2.7.0(0000.00*kW)	Actual power output (kW)
0-0:17.0.0(999*A)	Max current per phase (999=no max)
0-0:96.3.10(1)	Switch position
0-0:96.13.1()	Message code
0-0:96.13.0()	Message text
0-1:24.1.0(3)	Attached device type identifier
0-1:96.1.0(3238303131303031333035000000000000)	Serial number of gas meter
0-1:24.3.0(150613210000)(08)(60)(1)(0-1:24.2.1)(m3)	Time of last gas meter update
(01831.213)	Gas meter value (m³)
0-1:24.4.0(1)	Gas valve position
!	Telegram end-marker

A P1 telegram always begins with a forward slash (/) followed by a meter manufacturer identifier and serial number on the same line, and ends with an exclamation mark (!). Everything in between is measurement data: the beginning of each line tells us the type of measurement, and the actual value is between the parentheses.

Normally the T1 (1.8.1) and T2 (1.8.2) meter values are the only relevant ones, and the latter only if you have dual rate for electricity. As soon as you start feeding electricity back to the grid, the T3 (2.8.1) and T4 (2.8.2) values will be going up as well.

Three months ago, when I was just figuring this all out, we didn't have solar panels yet and I could safely interpret the sum of T1 and T2 as the energy consumption. This worked fine back then, but in a future post we'll see how solar panels ruin this interpretation, and come up with some more accurate terms.

The actual power input (1.7.0) and output (2.7.0) are snapshot values. They're nice for an indication of power input/output as real-time as it gets; for example, if you switch on the microwave, you'll see this power value shoot up in the next P1 telegram (ie. within 10 seconds). But besides that, they hardly provide any statistical value.

I'm unsure about the meaning of switch position (96.3.10) and valve position (24.4.0)... I tried closing the external gas valves, but it didn't affect the returned value. I haven't tested the RCD, mostly because it would require another power supply to keep the Raspberry Pi alive, and I did not care that much to bother.

It is noteworthy that gas meters are configured to report their values to the main meter only once per hour. This means that our P1 telegram also only contains the last reported gas meter value and the timestamp when this was updated. The format of this timestamp is (YYMMDDhhmmss), and the gas meter value is all by itself on a new line... a bit inconsistent formatting going on there.

Let's assume we have captured our example telegram in a text file; we can then use this simple 'awk' script to parse it:

# Initialization
BEGIN { FS="[:()*]" }

# Pattern matches to extract the fields we want
/1\.8\.1/   { l1 = $3; }
/1\.8\.2/   { l2 = $3; }
/2\.8\.1/   { t1 = $3; }
/2\.8\.2/   { t2 = $3; }
/96\.14\.0/ { ta = $3; }
/1\.7\.0/   { w1 = $3; }
/2\.7\.0/   { w2 = $3; }
/24\.3\.0/  { dt = $3; }
/^\(.*\)\r/ { g1 = $2; }

# Finally dump the variables into an array.
END { print ta,l1,l2,(l1+l2),t1,t2,(t1+t2),w1,w2,(w1+w2),g1,dt; }

Now that we have all our values of interest in a handy little bash array, it's time to automate and schedule the whole process and start thinking of what we can actually do with these measurements.