Earth Notes: Saving Electricity and Gas (2020)

The Loop gas monitoring stopped on October 20th, when some works were being done under the kitchen sink. It did not seem to be easily revivable.

Shortly afterwards Loop announced that the entire service was being discontinued. Annoyingly this means that the heating season is missed.

I attempted to restart discussions with Ecotricity to get a smart meter fitted, so long as I could get decent granularity gas readings, but that has not got anywhere.

The central heating was only switched on 1st December, whereas early November is more typical. HDD 12 for Novembers up to 2020, showing this November to be the warmest for 5 years, but not exceptional:

2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020
 134  128   75  179   66  133  139   79   63  154  128  101  141   87

We have subsequently been keeping most of the house on a nominal 17°C (2 on the Radbot dial) which should have reduced demand, though this December is looking to be on the cold side:

2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020
 192  233  236  328  154  190  152  183   38  160  187  128  153  186

And here are December gas usage numbers (kWh/HDD),. 16WW was recently partly vacant in 2020 (though I stayed), 2019 and 2017.

2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020
52.5 39   34   33   18   22   13   19    9.2 21   20   20   16   17

For my final statscast for the year, I looked at 16WW's load profile, ie when we demand electricity from the grid, or spill it back.

I looked at a variety of combinations of weekday and weekend and all week, winter and summer, and the difference that PV and a battery makes.

Without PV and battery, the shape of our consumption is probably fairly normal, though we are lowish (efficient) users. But things are different for actual grid imports and exports after PV and battery magic!

Weekday and weekend graphs and data for 202006.

CSV	CSV

Weekday and weekend graphs and data for 202012-01to21.

CSV	CSV

Calculating carbon emissions by time-of-day (ToD) involves the FUELINST data from Elexon / National Grid, and the locally sampled 16WW grid import/export flows using the Enphase system.

The actual resolution of the FUELINST data is probably the lowest available with some components delayed up to 30 minutes, though computed values will typically be stored at 5 or 10 minute intervals. The Enphase samples are usually every 5 minutes. Either can be stored more or less often, and duplicates are possible. Data is in datetime order and all timestamps are UTC.

The archived carbon-intensity data looks like:

% xz -d < data/FUELINST/log/2020.log.xz
# Retail GB electricity carbon intensity as computed by earth.org.uk.
# Time gCO2e/kWh
2020-01-01T00:05Z 210
2020-01-01T00:15Z 209
2020-01-01T00:25Z 210
2020-01-01T00:35Z 211
2020-01-01T00:50Z 213
2020-01-01T00:55Z 212
...

That second column is the effective grid carbon intensity for a domestic user, including transmission and distribution losses (currently 7%).

For the Enphase data the key value is the (number that follows) consumption.net.wNow, ie net grid flow.

% xz -d < data/16WWHiRes/Enphase/2020.log.xz
20200101T00:04Z consumption.readingTime 1577837027 consumption.net.wNow 142.092 consumption.total.wNow 138.065 production.wNow -4.027 storage.percentFull 0 storage.wNow -5 storage.readingTime 1577836931
20200101T00:09Z consumption.readingTime 1577837327 consumption.net.wNow 154.046 consumption.total.wNow 151.054 production.wNow -2.991 storage.percentFull 0 storage.wNow -5 storage.readingTime 1577837232
20200101T00:14Z consumption.readingTime 1577837626 consumption.net.wNow 152.356 consumption.total.wNow 149.169 production.wNow -3.186 storage.percentFull 0 storage.wNow -5 storage.readingTime 1577837532
20200101T00:19Z consumption.readingTime 1577837927 consumption.net.wNow 92.774 consumption.total.wNow 89.818 production.wNow -2.956 storage.percentFull 0 storage.wNow -5 storage.readingTime 1577837834
20200101T00:24Z consumption.readingTime 1577838228 consumption.net.wNow 70.484 consumption.total.wNow 67.792 production.wNow -2.692 storage.percentFull 0 storage.wNow -5 storage.readingTime 1577838132
...

(Using these actual relatively-fine-grained grid flows, ie net imports and exports, makes self-consumption disappear, eg at night with no imports when entirely running from battery. But the exports that then don't happen from PV generation become 'lost' negative emissions.)

The simplest approach, assuming no particular sampling bias, is to take the (arithmetic) mean of the pertinent values in each hour. Duplicates by time may possibly be discarded before the mean is taken.

The 1h-bucketed FUELINST values out/yearly/FUELINST-1h-2020.csv.gz are created by script/analytic/FUELINST-bucket-1h.sh. The format (with bucket hour start, in ISO 8601 format) is:

2020-01-01T00:00Z,210.833
2020-01-01T01:00Z,209.167
2020-01-01T02:00Z,206
2020-01-01T03:00Z,200.4
2020-01-01T04:00Z,182
...
2020-12-31T19:00Z,282.667
2020-12-31T20:00Z,269.5
2020-12-31T21:00Z,247.167
2020-12-31T22:00Z,236.4
2020-12-31T23:00Z,223.833

An arithmetic mean of those values indicates an annual mean of 216.365gCO2/kWh.

A sort reveals the range of intensities:

2020-12-18T03:00Z,74.3333
2020-11-12T03:00Z,75
...
2020-09-15T13:00Z,363.5
2020-08-27T11:00Z,364.5

The 1h-bucketed Enphase values out/yearly/Enphase-1h-2020.csv.gz are created by script/analytic/Enphase-bucket-1h.sh. The format (with bucket hour start, in ISO 8601 format) is:

2020-01-01T00:00Z,106.954
2020-01-01T01:00Z,72.0906
2020-01-01T02:00Z,77.9957
2020-01-01T03:00Z,81.7087
2020-01-01T04:00Z,71.7366

Note that neither generated file has entries for every one of the 8784 hours in the 2020 leap year, because machines and networks are down sometimes:

% gzip -d < out/yearly/Enphase-1h-2020.csv.gz | wc -l
8775
% gzip -d < out/yearly/FUELINST-1h-2020.csv.gz | wc -l
8745

The intersection of the two data sources is 8732 hours, ie 8732/8784 = 99.4% of all hours. It is probably reasonable to compute the carbon for the hours that are there, and scale up for the missing hours. Again. assuming no particular bias in the 'missing' hours. Note however, that some problems such as networking issues, may be left unresolved longer at night, when there is lower consumption, so a simple scale up may be on the conservative side, overestimating emissions.

% awk -F, '{print $1}' < Enphase-1h-2020.csv > E.dates
% awk -F, '{print $1}' < FUELINST-1h-2020.csv > F.dates
% wc -l E.dates F.dates
    8775 E.dates
    8745 F.dates
% comm -12 E.dates F.dates | wc -l
    8732

There are 56 hours that are in one data set but not the other:

% comm -3 ~/tmp/E.dates ~/tmp/F.dates | wc -l
    56
% comm -3 ~/tmp/E.dates ~/tmp/F.dates
2020-01-30T12:00Z
2020-02-13T11:00Z
2020-03-03T01:00Z
2020-03-03T02:00Z
2020-03-03T03:00Z
2020-03-05T20:00Z
2020-03-06T07:00Z
2020-03-06T08:00Z
        2020-03-24T13:00Z
        2020-03-24T14:00Z
2020-03-25T06:00Z
2020-04-30T10:00Z
2020-04-30T11:00Z
        2020-05-20T16:00Z
2020-05-28T18:00Z
2020-05-28T19:00Z
2020-05-28T20:00Z
2020-05-28T21:00Z
2020-05-28T22:00Z
2020-05-28T23:00Z
2020-05-29T00:00Z
2020-05-29T01:00Z
2020-07-13T23:00Z
2020-07-14T00:00Z
2020-07-14T01:00Z
2020-07-14T02:00Z
        2020-07-29T18:00Z
2020-08-06T10:00Z
        2020-08-18T17:00Z
2020-09-30T18:00Z
2020-09-30T19:00Z
2020-09-30T20:00Z
2020-09-30T21:00Z
2020-09-30T22:00Z
2020-09-30T23:00Z
2020-10-01T00:00Z
2020-10-15T23:00Z
        2020-10-21T15:00Z
2020-10-26T03:00Z
        2020-10-26T14:00Z
        2020-10-26T15:00Z
2020-10-26T19:00Z
2020-10-26T23:00Z
        2020-10-29T13:00Z
        2020-10-29T14:00Z
        2020-10-30T08:00Z
2020-11-10T08:00Z
2020-11-19T11:00Z
2020-11-19T12:00Z
2020-11-19T13:00Z
2020-11-27T16:00Z
2020-11-27T17:00Z
2020-12-03T19:00Z
        2020-12-14T20:00Z
        2020-12-14T22:00Z
2020-12-18T16:00Z

To join the hours that are present in both (confirming the same number of matched hours in the first instance):

% join -t, -j1 Enphase-1h-2020.csv FUELINST-1h-2020.csv | wc -l
    8732
% join -t, -j1 Enphase-1h-2020.csv FUELINST-1h-2020.csv | head
2020-01-01T00:00Z,106.954,210.833
2020-01-01T01:00Z,72.0906,209.167
2020-01-01T02:00Z,77.9957,206
2020-01-01T03:00Z,81.7087,200.4
2020-01-01T04:00Z,71.7366,182
2020-01-01T05:00Z,67.4731,180.333
2020-01-01T06:00Z,195.651,197.167
2020-01-01T07:00Z,162.984,205
2020-01-01T08:00Z,458.225,218.667
2020-01-01T09:00Z,293.469,240

(The join result is captured: out/yearly/Enphase-join-FUELINST-1h-2020.csv.gz.)

To compute the balance in kgCO2 for the year, between import and export (noting a scale down by 1000x1000 to allow for inputs being in Wh and g/kWh):

% join -t, -j1 ~/tmp/Enphase-1h-2020.csv ~/tmp/FUELINST-1h-2020.csv | \
      awk -F, '{sum += $2*$3} END {print sum/1000000}'
-374.478

Scaling up for the missing hours gives -377kgCO2.

This is less favourable (as expected) than the flat-rate 0.43kgCO2/kWh estimate of -717kgCO2 balance for electricity generation and consumption.

Given the 550kgCO2 emissions from burning gas, that gives a new overall balance for the house for electricity and gas of 173kgCO2, ie no longer negative.

A crude by-hour graph of imports and emissions (which can go negative) can be prepared with:

gnuplot -e "title='2020 CO2 emissions kg/h'" -e "infilename='Enphase-join-FUELINST-1h-2020.csv'" graphing/storesim/CO2-profile-1.txt