Same Procedure as Every Autumn: New Data for the Heat Pump System

October – time for updating documentation of the heat pump system again! Consolidated data are available in this PDF document.

In the last season there were no special experiments – like last year’s Ice Storage Challenge or using the wood stove. Winter was rather mild, so we needed only ~16.700kWh for space heating plus hot water heating. In the coldest season so far – 2012/13 – the equivalent energy value was ~19.700kWh. The house is located in Eastern Austria, has been built in the 1920s, and has 185m2 floor space since the last major renovation.

(More cross-cultural info:  I use thousands dots and decimal commas).

The seasonal performance factor was about 4,6 [kWh/kWh] – thus the electrical input energy was about 16.700kWh / 4,6 ~ 3.600kWh.

Note: Hot water heating is included and we use flat radiators requiring a higher water supply temperature than the floor heating loops in the new part of the house.

Heating season 2015/2016: Performance data for the 'ice-storage-/solar-powered' heat pump system

Red: Heating energy ‘produced’ by the heat pump – for space heating and hot water heating. Yellow: Electrical input energy. Green: Performance Factor = Ratio of these energies.

The difference of 16.700kWh – 3.600kWh = 13.100kWh was provided by ambient energy, extracted from our heat source – a combination of underground water/ice tank and an unglazed ribbed pipe solar/air collector.

The solar/air collector has delivered the greater part of the ambient energy, about 10.500kWh:

Heating season 2015/2016: Energy harvested from air by the collector versus heating-energy

Energy needed for heating per day (heat pump output) versus energy from the solar/air collector – the main part of the heat pump’s input energy. Negative collector energies indicate passive cooling periods in summer.

Peak Ice was 7 cubic meters, after one cold spell of weather in January:

Heating season 2015/2016: Temperature of ambient air, water tank (heat source) and volume of water frozen in the tank.

Ice is formed in the water tank when the energy from the collector is not sufficient to power the heat pump alone, when ambient air temperatures are close to 0°C.

Last autumn’s analysis on economics is still valid: Natural gas is three times as cheap as electricity but with a performance factor well above three heating costs with this system are lower than they would be with a gas boiler.

Is there anything that changed gradually during all these years and which does not primarily depend on climate? We reduced energy for hot tap water heating – having tweaked water heating schedule gradually: Water is heated up once per day and as late as possible, to avoid cooling off the hot storage tank during the night.

We have now started the fifth heating season. This marks also the fifth anniversary of the day we switched on the first ‘test’ version 1.0 of the system, one year before version 2.0.

It’s been about seven years since first numerical simulations, four years since I have been asked if I was serious in trading in IT security for heat pumps, and one year since I tweeted:

Re-Visiting Carnot’s Theorem

The proof by contradiction used in physics textbooks is one of those arguments that appear surprising, then self-evident, then deceptive in its simplicity. You – or maybe only: I – cannot resist turning it over and over in your head again, viewing it from different angles.

tl;dr: I just wanted to introduce the time-honored tradition of ASCII text art images to illustrate Carnot’s Theorem, but this post got out of hand when I mulled about how to  refute an erroneous counter-argument. As there are still research papers being written about Carnot’s efficiency I feel vindicated for writing a really long post though.

Carnot‘s arguments prove that there is a maximum efficiency of a thermodynamic heat engine – a machine that turns heat into mechanical energy. He gives the maximum value by evaluating one specific, idealized process, and then proves that a machine with higher efficiency would give rise to a paradox. The engine uses part of the heat available in a large, hot reservoir of heat and turns it into mechanical work and waste heat – the latter dumped to a colder ‘environment’ in a 4-step process. (Note that while our modern reformulation of the proof by contradiction refers to the Second Law of Thermodynamics, Carnot’s initial version was based on the caloric theory.)

The efficiency of such an engine η – mechanical energy per cycle over input heat energy – only depends on the two temperatures (More details and references here):

\eta_\text{carnot} = \frac {T_1-T_2}{T_1}

These are absolute temperatures in Kelvin; this universal efficiency can be used to define what we mean by absolute temperature.

I am going to use ‘nice’ numbers. To make ηcarnot equal to 1/2, the hot temperature
T1 = 273° = 546 K, and the colder ‘environment’ has T2 = 0°C = 273 K.

If this machine is run in reverse, it uses mechanical input energy to ‘pump’ energy from the cold environment to the hot reservoir – it is a heat pump using the ambient reservoir as a heat source. The Coefficient of Performance (COP, ε) of the heat pump is heat output over mechanical input, the inverse of the efficiency of the corresponding engine. εcarnot is 2 for the temperatures given above.

If we combine two such perfect machines – an engine and a heat pump, both connected to the hot space and to the cold environment, their effects cancel out: The mechanical energy released by the engine drives the heat pump which ‘pumps back’ the same amount of energy.

In the ASCII images energies are translated to arrows, and the number of parallel arrows indicates the amount of energy per cycle (or power). For each device, the number or arrows flowing in and out is the same; energy is always conserved. I am viewing this from the heat pump’s perspective, so I call the cold environment the source, and the hot environment room.

Neither of the heat reservoirs are heated or cooled in this ideal case as the same amount of energy flows from and to each of the heat reservoirs:

|         Hot room at temperature T_1 = 273°C = 546 K      |
           | | | |                         | | | |
           v v v v                         ^ ^ ^ ^
           | | | |                         | | | |
       |------------|                 |---------------|
       |   Engine   |->->->->->->->->-|   Heat pump   |
       |  Eta = 1/2 |->->->->->->->->-| COP=2 Eta=1/2 |
       |------------|                 |---------------|
             | |                             | |
             v v                             ^ ^
             | |                             | |
|        Cold source at temperature T_2 = 0°C = 273 K      | 

If either of the two machines works less than perfectly and in tandem with a perfect machine, anything is still fine:

If the engine is far less than perfect and has an efficiency of only 1/4 – while the heat pump still works perfectly – more of the engine’s heat energy input is now converted to waste heat and diverted to the environment:

|         Hot room at temperature T_1 = 273°C = 546 K      |
           | | | |                           | |  
           v v v v                           ^ ^  
           | | | |                           | |  
       |------------|                 |---------------|
       |   Engine   |->->->->->->->->-|   Heat pump   |
       |  Eta = 1/4 |                 | COP=2 Eta=1/2 |
       |------------|                 |---------------|
            | | |                             |
            v v v                             ^
            | | |                             |
|        Cold source at temperature T_2 = 0°C = 273 K      | 

Now two net units of energy flow from the hot room to the environment (summing up the arrows to and from the devices):

|         Hot room at temperature T_1 = 273°C = 546 K      |
                              | |                                
                              v v                                
                              | | 
                     |   Combination:   |
                     | Eta=1/4 COP=1/2  |
                              | |                              
                              v v                              
                              | |                             
|        Cold source at temperature T_2 = 0°C = 273 K      | 

Using a real-live heat pump with a COP of 3/2 (< 2) together with a perfect engine …

|         Hot room at temperature T_1 = 273°C = 546 K      |
          | | | |                             | | | 
          v v v v                             ^ ^ ^ 
          | | | |                             | | |
       |------------|                 |-----------------|
       |   Engine   |->->->->->->->->-|    Heat pump    |
       |  Eta = 1/2 |->->->->->->->->-|     COP=3/2     |
       |------------|                 |-----------------|
            | |                                 |
            v v                                 ^
            | |                                 |
|        Cold source at temperature T_2 = 0°C = 273 K      | 

… causes again a non-paradoxical net flow of one unit of energy from the room to the environment.

In the most extreme case  a poor heat pump (not worth this name) with a COP of 1 just translates mechanical energy into heat energy 1:1. This is a resistive heating element, a heating rod, and net heat fortunately flows from hot to cold without paradoxes:

|         Hot room at temperature T_1 = 273°C = 546 K      |
            | |                                |   
            v v                                ^   
            | |                                |   
       |------------|                 |-----------------|
       |   Engine   |->->->->->->->->-|   'Heat pump'   |
       |  Eta = 1/2 |                 |     COP = 1     |
       |------------|                 |-----------------|
|        Cold source at temperature T_2 = 0°C = 273 K      | 

The textbook paradox in encountered, when an ideal heat pump is combined with an allegedly better-than-possible engine, e.g. one with an efficiency:

ηengine = 2/3 (> ηcarnot = 1/2)

|         Hot room at temperature T_1 = 273°C = 546 K      |
           | | |                           | | | |
           v v v                           ^ ^ ^ ^
           | | |                           | | | |
       |------------|                 |---------------|
       |   Engine   |->->->->->->->->-|   Heat pump   |
       |  Eta = 2/3 |->->->->->->->->-| COP=2 Eta=1/2 |
       |------------|                 |---------------|
             |                               | |
             v                               ^ ^
             |                               | |
|        Cold source at temperature T_2 = 0°C = 273 K      | 

The net effect / heat flow is then:

|        Hot room at temperature T_1 = 273°C = 546 K       | 
                   |   Combination:   | 
                   | Eta=3/2; COP=1/2 | 
|       Cold source at temperature T_2 = 0°C = 273 K       | 

One unit of heat would flow from the environment to the room, from the colder to the warmer body without any other change being made to the system. The combination of these machines would violate the Second Law of Thermodynamics; it is a Perpetuum Mobile of the Second Kind.

If the heat pump has a higher COP than the inverse of the perfect engine’s efficiency, a similar paradox arises, and again one unit of heat flows in the forbidden direction:

|         Hot room at temperature T_1 = 273°C = 546 K      |
            | |                             | | |
            v v                             ^ ^ ^
            | |                             | | |
       |------------|                 |---------------|
       |   Engine   |->->->->->->->->-|   Heat pump   |
       |  Eta = 1/2 |                 |    COP = 3    |
       |------------|                 |---------------|
             |                               | |
             v                               ^ ^
             |                               | |
|        Cold source at temperature T_2 = 0°C = 273 K      | 

A weird question: Can’t we circumvent the paradox if we pair the impossible superior engine with a poor heat pump?

|         Hot room at temperature T_1 = 273°C = 546 K      |
           | | |                             | |  
           v v v                             ^ ^  
           | | |                             | |  
       |------------|                 |---------------|
       |   Engine   |->->->->->->->->-|   Heat pump   |
       |  Eta = 2/3 |->->->->->->->->-|    COP = 1    |
       |------------|                 |---------------|
|        Cold source at temperature T_2 = 0°C = 273 K      | 

Indeed: If the COP of the heat pump (= 1) is smaller than the inverse of the engine’s efficiency (3/2), there will be no apparent violation of the Second Law – one unit of net heat flows from hot to cold.

An engine with low efficiency 1/4 would ‘fix’ the second paradox involving the better-than-perfect heat pump:

|         Hot room at temperature T_1 = 273°C = 546 K      |
           | | | |                          | | |
           v v v v                          ^ ^ ^
           | | | |                          | | |
       |------------|                 |---------------|
       |   Engine   |->->->->->->->->-|   Heat pump   |
       |  Eta = 1/4 |                 |     COP=3     |
       |------------|                 |---------------|
            | | |                            | |
            v v v                            ^ ^
            | | |                            | |
|        Cold source at temperature T_2 = 0°C = 273 K      | 

But we cannot combine heat pumps and engines at will, just to circumvent the paradox – one counter-example is sufficient: Any realistic engine combined with any realistic heat pump – plus all combinations of those machines with ‘worse’ ones – have to result in net flow from hot to cold …

The Second Law identifies such ‘sets’ of engines and heat pumps that will all work together nicely. It’s easier to see this when all examples are condensed into one formula:

The heat extracted in total from the hot room – Q1 –  is the difference of heat used by the engine and heat delivered by the heat pump, both of which are defined in relation to the same mechanical work W:

Q_1 = W\left (\frac{1}{\eta_\text{engine}}-\varepsilon_\text{heatpump}\right)

This is also automatically equal to Qas another quick calculation shows or by just considering that energy is conserved: Some heat goes into the combination of the two machines, part of it – W – flows internally from the engine to the heat pump. But no part of the input Q1 can be lost, so the output of the combined machine has to match the input. Energy ‘losses’ such as energy due to friction will flow to either of the heat reservoirs: If an engine is less-then-perfect, more heat will be wasted to the environment; and if the heat pump is less-than-perfect a greater part of mechanical energy will be translated to heat only 1:1. You might be even lucky: Some part of heat generated by friction might end up in the hot room.

As Q1 has to be > 0 according to the Second Low, the performance numbers have to related by this inequality:


The equal sign is true if the effects of the two machines just cancel each other.

If we start from a combination of two perfect machines (ηengine = 1/2 = 1/εheatpump) and increase either ηengine or εheatpump, this condition would be violated and heat would flow from cold to hot without efforts.

But also an engine with efficiency = 1 would work happily with the worst heat pump with COP = 1. No paradox would arise at first glance  – as 1/1 >= 1:

|         Hot room at temperature T_1 = 273°C = 546 K      |
             |                                |   
             v                                ^   
             |                                |   
       |------------|                 |-----------------|
       |   Engine   |->->->->->->->->-|   'Heat pump'   |
       |   Eta = 1  |                 |      COP=1      |
       |------------|                 |-----------------|
|        Cold source at temperature T_2 = 0°C = 273 K      | 

What’s wrong here?

Because of conservation of energy ε is always greater equal 1; so the set of valid combinations of machines all consistent with each other is defined by:


… for all efficiencies η and COPs / ε of machines in a valid set. The combination η = ε = 1 is still not ruled out immediately.

But if the alleged best engine (in a ‘set’) would have an efficiency of 1, then the alleged best heat pump would have an Coefficient of Performance of only 1 – and this is actually the only heat pump possible as ε has to be both lower equal and greater equal than 1. It cannot get better without creating paradoxes!

If one real-live heat pump is found that is just slightly better than a heating rod – say
ε = 1,1 – then performance numbers for the set of consisent, non-paradoxical machines need to fulfill:

\eta_\text{engine}\leq\eta_\text{best engine}


\varepsilon_\text{heatpump}\leq\varepsilon_\text{best heatpump}

… in addition to the inequality relating η and ε.

If ε = 1,1 is a candidate for the best heat pump, a set of valid machines would comprise:

  • All heat pumps with ε between 1 and 1,1 (as per limits on ε)
  • All engines with η between 0 and 0,9 (as per inequality following the Second Law plus limit on η).

Consistent sets of machines are thus given by a stronger condition – by adding a limit for both efficiency and COP ‘in between’:

\frac{1}{\eta_\text{engine}}\geq\text{Some Number}\geq\varepsilon_\text{heatpump}\geq1

Carnot has designed a hypothetical ideal heat pump that could have a COP of εcarnot = 1/ηcarnot. It is a limiting case of a reversible machine, but feasible on principle. εcarnot  is thus a valid upper limit for heat pumps, a candidate for Some Number. In order to make this inequality true for all sets of machines (ideal ones plus all worse ones) then 1/ηcarnot = εcarnot also constitutes a limit for engines:


So in order to rule out all paradoxes, Some Number in Between has to be provided for each set of machines. But what defines a set? As machines of totally different making have to work with each other without violating this equality, this number can only be a function of the only parameters characterizing the system – the two temperatures

Carnot’s efficiency is only a function of the temperatures. His hypothetical process is reversible, the machine can work either as a heat pump or an engine. If we could come up with a better process for a reversible heat pump (ε > εcarnot), the machine run in reverse would be an engine with η less than ηcarnot, whereas a ‘better’ engine would lower the upper bound for heat pumps.

If you have found one truly reversible process, both η and ε associated with it are necessarily the upper bounds of performance of the respective machines, so you cannot push Some Number in one direction or the other, and the efficiencies of all reversible engines have to be equal – and thus equal to ηcarnot. The ‘resistive heater’ with ε = 1 is the iconic irreversible device. It will not turn into a perfect engine with η = 1 when ‘run in reverse’.

The seemingly odd thing is that 1/ηcarnot appears like a lower bound for ε at first glance if you just declare ηcarnot an upper bound for corresponding engines and take the inverse, while in practice and according to common sense it is the maximum value for all heat pumps, including irreversible ones. (As a rule of thumb a typical heat pump for space heating has a COP only 50% of 1/ηcarnot.)

But this ‘contradiction’ is yet another way of stating that there is one universal performance indicator of all reversible machines making use of two heat reservoirs: The COP of a hypothetical ‘superior’ reversible heat pump would be at least 1/ηcarnot  … as good as Carnot’s reversible machine, maybe better. But the same is true for the hypothetical superior engine with an efficiency of at least ηcarnot. So the performance numbers of all reversible machines (all in one set, characterized by the two temperatures) have to be exactly the same.

Steam pump / Verkehrt laufende Dampfmaschine

Historical piston compressor (from the time when engines with pistons looked like the ones in textbooks), installed 1878 in the salt mine of Bex, Switzerland. 1943 it was still in operation. Such machines used in salt processing were considered the first heat pumps.

Hacking My Heat Pump – Part 2: Logging Energy Values

In the last post, I showed how to use Raspberry Pi as CAN bus logger – using a test bus connected to control unit UVR1611. Now I have connected it to my heat pump’s bus.

Credits for software and instructions:

Special thanks to SK Pang Electronics who provided me with CAN boards for Raspberry Pi after having read my previous post!!

CAN boards for Raspberry Pi, by SK Pang

CAN extension boards for Raspberry Pi, by SK Pang. Left: PiCAN 2 board (40 GPIO pins), right: smaller, retired PiCAN board with 26 GPIO pins – the latter fits my older Pi. In contrast to the board I used in the first tests, these have also a serial (DB9) interface.

Wiring CAN bus

We use a Stiebel-Eltron WPF 7 basic heat pump installed in 2012. The English website now refers to model WPF 7 basic s.

The CAN bus connections described in the German manual (Section 12.2.3) and the English manual (Wiring diagram, p.25) are similar:

Stiebel-Eltron WPF 7 basic - CAN bus connections shown in German manual

CAN bus connections inside WPF 7 basic heat pump. For reference, see the description of the Physical Layer of the CAN protocol. Usage of the power supply (BUS +) is optional.

H, L and GROUND wires from the Pi’s CAN board are connected to the respective terminals inside the heat pump. I don’t use the optional power supply as the CAN board is powered by Raspberry Pi, and I don’t terminate the bus correctly with 120 Ω. As with the test bus, wires are rather short and thus have low resistance.

Stiebel-Eltron WPF 7 basic - CAN bus connections inside the heat pump, cable from Raspberry Pi connected.

Heat pump with cover removed – CAN High (H – red), Low (L – blue), and Ground (yellow) are connected. The CAN cable is a few meters long and connects to the Raspberry Pi CAN board.

In the first tests Raspberry Pi had the privilege to overlook the heat pump room as the top of the buffer tank was the only spot the WLAN signal was strong enough …

Raspberry Pi, on top of the buffer tank

Typical, temporary nerd’s test setup.

… or I used a cross-over ethernet cable and a special office desk:

Working on the heat pump - Raspberry Pi adventures

Typical, temporary nerd’s workplace.

Now Raspberry Pi has its final position on the ‘organic controller board’, next to control unit UVR16x2 – and after a major upgrade to both LAN and WLAN all connections are reliable.

Raspberry Pi with PiCAN board from SK Pang and UVR16x2

Raspberry Pi with PiCAN board from SK Pang and UVR16x2 control unit from Technische Alternative (each connected to a different CAN bus).

Bringing up the interface

According to the bit rate of Stiebel-Eltron’s bus is 20000 bit/s; so the interface is activated with:

sudo ip link set can0 type can bitrate 20000
sudo ifconfig can0 up

Watching the idle bus

First I was simply watching with sniffer Wireshark if the heat pump says anything without being triggered. It does not – only once every few minutes there are two packets. So I need to learn to talk to it.

Learning about CAN communications

SK Pang provides an example of requesting data using open source tool cansend: The so-called CAN ID is followed by # and the actual data. This CAN ID refers to an ‘object’ – a set of properties of the device, like the set of inputs or outputs – and it can contain also the node ID of the device on the bus. There are many CAN tutorials on the net, I found this (German) introduction and this English tutorial very useful.

I was able to follow the communications of the two nodes in my test bus as I knew their node numbers and what to expect – the data logger would ask the controller for a set of configured sensor outputs every minute. Most packets sent by either bus member are related to object 480, indicating the transmission of a set of values (Process Data Exchange Objects, PDOs. More details on UVR’s CAN communication, in German)

Network trace on test CAN bus: UVR1611 and BL-NET

Sniffing test CAN bus – communication of UVR1611 (node no 1) and logger BL-NET (node number 62 = be). Both devices use an ID related to object ID 480 plus their respective node number, as described here.

So I need to know object ID(s) and properly formed data values to ask the heat pump for energy readings – without breaking something by changing values.

Collecting interesting heat pump parameters for monitoring

I am very grateful for Jürg’s CAN tool can_scan that allow for querying a Stiebel-Eltron heat pump for specific values and also for learning about all possible parameters (listed in so-called Elster tables).

In order to check the list of allowed CAN IDs used by the heat pump I run:

./can_scan can0 680

can0 is the (default) name of the interface created earlier and 680 is my (the sender’s) CAN ID, one of the IDs allowed by can_scan.

Start of output:

elster-kromschroeder can-bus address scanner and test utility
copyright (c) 2014 Jürg Müller, CH-5524

scan on CAN-id: 680
list of valid can id's:

  000 (8000 = 325-07)
  180 (8000 = 325-07)
  301 (8000 = 325-07)
  480 (8000 = 325-07)
  601 (8000 = 325-07)

In order to investigate available values and their meaning I run can_scan for each of these IDs:

./can_scan can0 680 180

Embedded below is part of the output, containing some of the values (and /* Comments */). This list of parameters is much longer than the list of values available via the display on the heat pump!

I am mainly interested in metered energies and current temperatures of the heat source (brine) and the ‘environment’ – to compare these values to other sensors’ output:

elster-kromschroeder can-bus address scanner and test utility
copyright (c) 2014 Jürg Müller, CH-5524

0001:  0000  (FEHLERMELDUNG  0)
0003:  019a  (SPEICHERSOLLTEMP  41.0)
0005:  00f0  (RAUMSOLLTEMP_I  24.0)
0006:  00c8  (RAUMSOLLTEMP_II  20.0)
0007:  00c8  (RAUMSOLLTEMP_III  20.0)
0008:  00a0  (RAUMSOLLTEMP_NACHT  16.0)
0009:  3a0e  (UHRZEIT  14:58)
000a:  1208  (DATUM  18.08.)
000c:  00e9  (AUSSENTEMP  23.3) /* Ambient temperature */
000d:  ffe6  (SAMMLERISTTEMP  -2.6)
000e:  fe70  (SPEICHERISTTEMP  -40.0)
0016:  0140  (RUECKLAUFISTTEMP  32.0) /* Heating water return temperature */
01d4:  00e2  (QUELLE_IST  22.6) /* Source (brine) temperature */
/* Hot tap water heating energy MWh + kWh */
/* Daily totaly */   
092a:  030d  (WAERMEERTRAG_WW_TAG_WH  781)
092b:  0000  (WAERMEERTRAG_WW_TAG_KWH  0)
/* Total energy since system startup */
092c:  0155  (WAERMEERTRAG_WW_SUM_KWH  341)
092d:  001a  (WAERMEERTRAG_WW_SUM_MWH  26)
/* Space heating energy, MWh + kWh */
/* Daily totals */
092e:  02db  (WAERMEERTRAG_HEIZ_TAG_WH  731)
/* Total energy since system startup */
0930:  0073  (WAERMEERTRAG_HEIZ_SUM_KWH  115)
0931:  0027  (WAERMEERTRAG_HEIZ_SUM_MWH  39)

Querying for one value

The the heating energy to date in MWh corresponds to index 0931:

./can_scan can0 680 180.0931

The output of can_scan already contains the sum of the MWh (0931) and kWh (0930) values:

elster-kromschroeder can-bus address scanner and test utility
copyright (c) 2014 Jürg Müller, CH-5524

value: 0027  (WAERMEERTRAG_HEIZ_SUM_MWH  39.115)

The network trace shows that the logger (using ID 680) queries for two values related to ID 180 – the kWh and the MWh part:

Network trace on heat pump's CAN bus: Querying for space heating energy to date.

Network trace of Raspberry Pi CAN logger (ID 680) querying CAN ID 180. Since the returned MWh value is the sum of MWh and kWh value, two queries are needed. Detailed interpretation of packets in the text below.

Interpretation of these four packets – as explained on Jürg’s website here and here in German:

00 00 06 80 05 00 00 00 31 00 fa 09 31  
00 00 01 80 07 00 00 00 d2 00 fa 09 31 00 27
00 00 06 80 05 00 00 00 31 00 fa 09 30 
00 00 01 80 07 00 00 00 d2 00 fa 09 30 00 73
|---------| ||          |---| || |---| |---|
1)          2)          3)    4) 5)    6)

1) CAN-ID used by the sender: 180 or 680 
2) No of bytes of data - 5 for queries, 8 for replies
3) CAN ID of the communications partner and type of message. 
For queries the second digit is 1. 
Pattern: n1 0m with n = 180 / 80 = 3 (hex) and m = 180 mod 7 = 0 
(hex) Partner ID = 30 * 8 (hex) + 00 = 180 
Responses follow a similar pattern using second digit 2: 
Partner ID is: d0 * 8 + 00 = 680 
4) fa indicates that the Elster index no is greater equal ff. 
5) Index (parameter) queried for: 0930 for kWh and 0931 for MWh
6) Value returned 27h=39,73h=115

I am not sure which node IDs my logger and the heat pump use as the IDs. 180 seems to be an object ID without node ID added while 301 would refer to object ID + node ID 1. But I suppose with two devices on the bus only, and one being only a listener, there is no ambiguity.

Logging script

I found all interesting indices listed under CAN ID 180; so am now looping through this set once every three minutes with can_scan, cut out the number, and add it to a new line in a text log file. The CAN interfaces is (re-)started every time in case something happens, and the file is sent to my local server via FTP.

Every month a new log file is started, and log files – to be imported into my SQL Server  and processed as log files from UVR1611 / UVR16x2, the PV generator’s inverter, or the smart meter.

(Not the most elegant script – consider it a ‘proof of concept’! Another option is to trigger the sending of data with can_scan and collect output via can_logger.)

Interesting to-be-logged parameters are added to a ‘table’ – a file called indices:



# Define folders

# FTP parameters

# Exit if scripts not found
if ! [ -d $scriptsdir ] 
    echo Directory $scriptsdir does not exist!
    exit 1

# Create log dir if it does not exist yet
if ! [ -d $logdir ] 
    mkdir $logdir

sleep 5

echo ======================================================================

# Start logging
while [ 0 -le 1 ]

# Get current date and start new logging line
now=$(date +'%Y-%m-%d;%H:%M:%S')
year=$(date +'%Y')
month=$(date +'%m')

# Create a new file for every month, write header line
# Create a new file for every month
if ! [ -f $logfilepath ] 
    headers="Datum Uhrzeit"
    while read indexline
        header=$(echo $indexline | cut -d" " -f2) 
    done < $indexfile ; echo "$headers" > $logfilepath 

# (Re-)start CAN interface
    sudo ip link set can0 type can bitrate 20000
    sudo ip link set can0 up

# Loop through interesting Elster indices
while read indexline
    # Get output of can_scan for this index, search for line with output values
    index=$(echo $indexline | cut -d" " -f1)
    value=$($scriptsdir/./can_scan can0 680 180.$index | grep "value" | replace ")" "" | grep -o "\<[0-9]*\.\?[0-9]*$" | replace "." ",")     
    echo "$index $value"     

    # Append value to line of CSV file     
done < $indexfile ; echo $line >> $logfilepath

# echo FTP log file to server
ftp -n -v $ftphost << END_SCRIPT
user $ftpuser $ftppw
cd RPi
lcd $logdir
put $logfile

echo "------------------------------------------------------------------"

# Wait - next logging data point
sleep 180

# Runs forever, use Ctrl+C to stop

In order to autostart the script I added a line to the rc.local file:

su pi -c '/CAN_SCRIPTS/pkt_can_monitor'

Using the logged values

In contrast to brine or water temperature heating energies are not available on the heat pump’s CAN bus in real-time: The main MWh counter is only incremented once per day at midnight. Then the daily kWh counter is added to the previous value.

Daily or monthly energy increments are calculated from the logged values in the SQL database and for example used to determine performance factors (heating energy over electrical energy) shown in our documentation of measurement data for the heat pump system.

First Year of Rooftop Solar Power and Heat Pump: Re-Visiting Economics

After I presented details for selected days, I am going to review overall performance in the first year. From June 2015 to May 2016 …

  • … we needed 6.600 kWh of electrical energy in total.
  • The heat pump consumed about 3.600 kWh of that …
  • … in order to ‘pump it up to’ 16.800 kWh of heating energy (incl. hot tap water heating). This was a mild season! .
  • The remaining 3.000kWh were used by household and office appliances, control, and circulation pumps.

(Disclaimer: I am from Austria –> decimal commas and dot thousands separator 🙂

The photovoltaic generator …

  • … harvested about 5.600kWh / year – not too bad for our 4,8kW system with panels oriented partly south-east and partly south-west.
  • 2.000 kWh of that were used directly and the rest was fed into the grid.
  • So 30% of our consumption was provided directly by the PV generator (self-sufficiency quota) and
  • 35% of PV energy produced was utilized immediately (self-consumption quota).

Monthly energy balances show the striking difference between summer and winter: In summer the small energy needed to heat hot water can easily be provided by solar power. But in winter only a fraction of the energy needed can be harvested, even on perfectly sunny days.

Figures below show…

  • … the total energy consumed in the house as the sum of the energy for the heat pump and the rest used by appliances …
  • … and as the sum of energy consumed immediately and the rest provided by the utility.
  • The total energy ‘generated’ by the solar panels, as a sum of the energy consumed directly (same aqua bar as in the sum of consumption) and the rest fed into the grid.

Monthly energy balances for photovoltaic generator: Energy used directly versus fed into grid

Monthly energy balances: Electrical energy used in total and energy used by the heat pump.

In June we needed only 300kWh (10kWh per day). The PV total output was more then 700kWh, and 200kW of that was directly delivered by the PV system – so the PV generator covered 65%. It would be rather easy to become autonomous by using a small, <10kWh battery and ‘shifting’ the missing 3,3kWh per day from sunny to dark hours.

But in January we needed 1100kWh and PV provided less than 200kWh in total. So a battery would not help as there is no energy left to be ‘shifted’.

Daily PV energy balances show that this is true for every single day in January:

Monthly energy balances for photovoltaic generator in January 2016: Energy used directly versus fed into grid.

We harvest typically less than 10 kWh per day, but we need  more than 30kWh. On the coldest days in January, the heat pump needed about 33kWh – thus heating energy was about 130kWh:

Monthly energy balances in January 2016: Electrical energy used in total and energy used by the heat pump.

Our house’s heat consumption is typical for a well-renovated old building. If we would re-build our house from scratch, according to low energy standards, we might need only 50-60% energy at best. Then heat pump’s input energy could be cut in half (violet bar). But even then, daily total energy consumption would exceed PV production.


I have covered economics of the system without battery here and our system has lived up to the expectations: Profits were € 575, the sum of energy sales at market price  (€ 0,06 / kWh) and by not having to pay € 0,18 for power consumed directly.

In Austria turn-key PV systems (without batteries) cost about € 2.000 / kW rated power – so we earned about 6% of the costs. Not bad – given political discussions about negative interest rates. (All numbers are market prices, no subsidies included.)

But it is also interesting to compare profits to heating costs: In this season electrical energy needed for the heat pump translates to € 650. So our profits from the PV generator nearly amounts to the total heating costs.

Economics of batteries

Last year’s assessment of the economics of a system with battery is still valid: We could increase self-sufficiency from 30% to 55% using a battery and ‘shift’ additional 2.000 kWh to the dark hours. This would result in additional € 240 profits of per year.

If a battery has a life time of 20 years (optimistic estimate!) it must not cost more than € 5.000 to ever pay itself off. This is less than prices I have seen in quotes so far.

Off-grid living and autonomy

Energy autonomy might be valued more than economical profits. Some things to consider:

Planning a true off-grid system is planning for a few days in a row without sunshine. Increasing the size of the battery would not help: The larger the battery the larger the losses, and in winter the battery would never be full. It is hard to store thermal energy for another season, but it is even harder to store electrical energy. Theoretically, the area of panels could be massively oversized (by a factor – not a small investment), but then even more surplus has to be ‘wasted’ in summer.

The system has to provide enough energy per day and required peak load in every moment (see spikes in the previous post), but power needs also to be distributed to the 3 phases of electrical power in the right proportion: In Austria energy meters calculate a sum over 3 phases: A system might seem ‘autonomous’ when connected to the grid, but it would not be able to operate off-grid. Example: The PV generator produces 1kW per phase = 3kW in total, while 2kW are used by a water cooker on phase 1. The meter says you feed in 1kW to the grid, but technically you need 1kW extra from the grid for the water cooker and feed in 1kW on phase 2 and 3 each; so there is a surplus of 1kW in total. Disconnected from the grid, the water cooker would not work as 1kW is missing.

A battery does not provide off-grid capabilities automatically, nor do PV panels provide backup power when the sun is shining but the grid is down: During a power outage the PV system’s inverter has to turn off the whole system – otherwise people working on the power lines outside could be hurt by the power fed into the grid. True backup systems need to disconnect from the power grid safely first. Backup capabilities need to be compliant with local safety regulations and come with additional (potentially clunky / expensive) gadgets.


Photovoltaic Generator and Heat Pump: Daily Power Generation and Consumption

You can generate electrical power at home but you cannot manufacture your own natural gas, oil, or wood. (I exempt the minority of people owning forestry). This is often an argument for the combination of heat pump and photovoltaic generator.

Last year I blogged in detail about economics of solar power and batteries and on typical power consumption and usage patterns – and my obsession with tracking down every sucker for electrical energy. Bottom line: Despite related tinkering with control and my own ‘user behaviour’ it is hard to raise self-consumption and self-sufficiency above statistical averages for homes without heat pumps.

In this post I will focus on load profiles and power generation during several selected days to illustrate these points, comparing…

  • electrical power provided by the PV generator (logged at Fronius Symo inverter).
  • input power needed by the heat pump (logged with energy meter connected to our control unit).
  • … power balanced provided by the smart meter: Power is considered positive when fed into the grid is counted  (This meter is installed directly behind the utility’s meter)

A non-modulating, typical brine-water heat pump is always operating at full rated power: We have a 7kW heat pump – 7kW is about the design heat load of the building, as worst case estimate for the coldest day in years. On the coldest day in the last winter the heat pump was on 75% of the time.

Given a typical performance factor of 4 kWh/kWh), the heat pump needs 1/4 of its rated power as input. Thus the PV generator needs to provide about 1-2 kW when the heat pump is on. The rated power of our 18 panels is about 5kW – this is the output under optimum conditions.

Best result near winter solstice

If it is perfectly sunny in winter, the generator can produce enough energy to power the heat pump between 10:00 and 14:00 in the best case.

2015-12-31: Photovoltaics and Power Consumption, Heat Pump's Compressor

But such cloudless days are rare, and in the cold and long nights considerable electrical energy is needed, too.

Too much energy in summer

On a perfect summer day hot water could even be heated twice a day by solar power:

2015-07-01: Photovoltaics and Power Consumption, Heat Pump's Compressor

These peaks look more impressive than they are compared to the base load: The heat pump needs only 1-2kWh per day compared to 10-11kWh total consumption.

Harvesting energy in spring

On a sunny day in spring the PV output is higher than in summer due to lower ambient temperatures. As we still need space heating energy this energy can also be utilized better:

2016-04-29: Photovoltaics and Power Consumption, Heat Pump's Compressor

The heat pump’s input power is similar to the power of a water heater or an electrical stoves. At noon on a perfect day both the heat pump and one appliance could be run on solar power only.

The typical day: Bad timing

On typical days clouds pass and power output changes quickly. This is an example of a day when sunshine and hot water cycle did not overlap much:

2016-03-29: Photovoltaics and Power Consumption, Heat Pump's Compressor

At noon the negative peak (power consumption, blue) was about 3,5kW. Obviously craving coffee or tea was string than the obsession with energy efficiency. Even the smartest control system would not be able to predict such peaks in both solar radiation and in erratic user behavior. Therefore I am also a bit sceptical when it comes to triggering the heat pump’s heating cycle by a signal from the PV generator, based on current and ‘expected’ sunshine and weather data from internet services (unless you track individual clouds).

Everything as a Service

Three years ago I found a research paper that proposed a combination of distributed computing and heating as a service: A cloud provider company like Google or Amazon would install computers in users’ homes – as black-boxes providing heat to the users and computing power to their cloud.

In the meantime I have encountered announcements of startups very similar to this idea. So finally after we have been reading about the Internet of Things every day, buzz words associated with IT infrastructure enter the real world of hand-on infrastructure.

I believe that heating will indeed be offered as a service and like cloud-based IT services: The service provider will install a box in your cellar – a black-box in terms of user access, more like a home router operated by the internet provider today. It will be owned and operated by a provider you have a service contract with. There will be defined and restricted interfaces for limited control and monitoring – such as setting non-critical parameters like room temperature or viewing hourly and daily statistics.

Heating boxes will get smaller, more compact, and more aesthetically pleasing. They might rather be put in the hall rather than being tucked away in a room dedicated to technical gadgets. This is in line with a trend of smaller and smaller boiler rooms for larger and larger houses. Just like computers and routers went from ugly, clunky boxes to sleek design and rounded corners, heating boxes will more look like artistic stand-alone pillars. I remember a German startup which offered home batteries this beautiful a few years back – but they switched to another business model as they seem to have been too early.

Vendors of heating systems will try to simplify their technical and organizational interfaces with contractors: As one vendor of heat pump systems told me they were working on a new way of exchanging parts all at once so that a technician certified in handling refrigerants will not be required. Anything that can go wrong on installation will go wrong no matter how detailed the checklist for the installer is – also inlet and outlet do get confused. A vendor’s vision is rather a self-contained box delivered to the client, including heating system(s), buffer storage tanks for heating water, and all required sensors, electrical wiring, and hydraulic connections between these systems – and there are solutions like that offered today.

The vendor will have secured access to this system over the internet. They will be able to monitor continuously, detect errors early and automatically, and either fix them remotely or notify the customer. In addition, vendors will be able to optimize their designed by analyzing consolidated data gathered from a large number of clients’ systems. This will work exactly in the way vendors of inverters for photovoltaic systems deal with clients’ data already today: User get access to a cloud-based portal and show off their systems and data, and maybe enter a playful competition with other system owners – what might work for smart metering might work for related energy systems, too. The vendor will learn about systems’ performance data for different geographical regions and different usage patterns.

District heating is already offered as a service today: The user is entitled to using hot water (or cold water in case a heat pump’s heat source is shared among different users). Users sometimes dislike the lack of control and the fact they cannot opt out – as district heating only works economically if a certain number of homes in a certain area is connected to the service. But in some pilot areas in Germany and Austria combined heat and power stations have already been offered as a service and a provider-operated black-box in the user’s home.

The idea of having a third external party operating essential infrastructure now owned by an end-user may sound uncommon but we might get used to it when gasoline-powered cars in a user’s possession will be replaced by electrical vehicles and related services: like having a service contractor for a battery instead of owning it. We used to have our own computer with all our data on it, and we used to download our e-mail onto it, delete it from the server, and deal with local backups. Now all of that is stored on a server owned by somebody else and which we share with other users. The incentive is the ease of access to our data from various devices and the included backup service.

I believe that all kinds of things and products as a service will be further incentivized by bundling traditionally separate products: I used to joke about the bank account bundled with electrical power, home insurance, and an internet plus phone flat rate – until the combined bank account and green power offering was shown on my online banking’s home screen. Bundling all these services will be attractive, and users might be willing to trade in their data for a much cheaper access to services – just as a non-sniffing smart phone is more expensive than its alternatives.

Heat pump - not cloud-powered.I withhold judgement as I think there is a large grey and blurry area between allegedly evil platforms that own our lives and justified outsourcing to robust and transparent services that are easy to use also by the non tech-savvy.

Update 2016-06-02 : Seems I could not withold judgement in the comments 🙂 I better admit it here as the pingback from the book Service Innovation’s blog here might seem odd otherwise 😉

The gist of my argument made in the comments was:

I believe that artisans and craftsmen will belong in one of two categories in the future:
1) Either working as subcontractor, partner, or franchisee of large vendors, selling and installing standardized products – covering the last mile not accessible to robots and software (yet),
2) Or a lucky few will carve out a small niche and produce or customize bespoke units for clients who value luxurious goods for the sake of uniqueness or who value human imperfection as a fancy extra.

In other communication related to this post I called this platform effects Nassim Taleb’s Extremistan versus Mediocristan in action – the platform takes it all. Also ever growing regulation will help platforms rather than solo artisans as only large organizations can deal effectively with growing requirements re compliance – put forth both by government and by large clients or large suppliers.

Rowboats, Laser Pulses, and Heat Energy (Boring Title: Dimensional Analysis)

Dimensional analysis means to understand the essentials of a phenomenon in physics and to calculate characteristic numbers – without solving the underlying, often complex, differential equation. The theory of fluid dynamics is full of interesting dimensionless numbers –  Reynolds Number is perhaps most famous.

In the previous post on temperature waves I solved the Heat Equation for a very simple case, in order to answer the question How far does solar energy get into ground in a year? Reason: I have been working on simulations of our heat pump system since a few years. This also involves heat transport between the water/ice tank and ground. If you set out to simulate a complex phenomenon you have to make lots of assumptions about materials’ parameters, and you have to simplify the system and equations you use for modelling the real world. You need a way of cross-checking if your results sound plausible in terms of orders of magnitude. So my goal has been to find yet another method to confirm assumptions I have made about the thermal properties of ground elsewhere.

Before I am going to revisit heat transport, I’ll try to explain what dimensional analysis is – using the best example I’ve ever seen. I borrow it from theoretical physicist – and awesome lecturer – David Tong:

How does the speed of a rowing boat depend in the number of rowers?

References: Tong’s lecture called Dynamics and Relativity (Chapter 3), This is the original paper from 1971 Tong quotes: Rowing: A similarity analysis.

College boat v1 c1830The boat experiences a force of friction in water. As for a car impeded by the friction of the surrounding air, the force of friction depends on velocity.

Force is the change of momentum, momentum is proportional to mass times velocity. Every small ‘parcel’ of water carries a momentum proportional to speed – so force should at least be proportional to one factor of v. But these parcel move at a speed v, so the faster they move the more momentum is exchanged with the boat; so there has to be a second factor of v, and force is proportional to the square of the speed of the boat.

The larger the cross-section of the submerged part of the boat, A, the higher is the number of collisions between parcels of water and the boat, so putting it together:

F \sim v^{2}A

Rowers need to put in power to compensate for friction. Power is energy per time, and Energy is force times distance. Since distance over time is velocity, thus power is also force times velocity.

So there is one more factor of v to be included in power:

P \sim v^{3}A

For the same reason wind power harvested by wind turbines is proportional to the third power of wind speed.

A boat does not sink because downward gravity and upward buoyancy just compensate each other; buoyancy is the weight of the volume of water displaced. The heavier the load, the more water needs to be displaced. The submerged volume of the boat V is proportional to the weight of the rowers, and thus to their number N if the mass of the boat itself is negligible:

V \sim N

The volume of something scales with the third power of its linear dimensions – think of a cube or a sphere; so the surface area scales with the square of the length, and the cross-section A scales with V – and thus with N:

A \sim N^{\frac{2}{3}}

Each rower contributes the same share to the total rowing power, so:

P \sim N

Inserting for A in the first expression for P:

P \sim v^{3} N^{\frac{2}{3}}

Eliminating P as it has been shown to be proportional to N:

N \sim v^{3} N^{\frac{2}{3}}
v^{3} \sim N^{\frac{1}{3}}
v \sim N^{\frac{1}{9}}

… which is in good agreement with measurements according to Tong.

Heat Transport and Characteristic Lengths

In the last post I’ve calculated characteristic lengths, describing how heat is slowly dissipated in ground: 1) The wavelength of the damped oscillation and 2) the run-out length of the enveloping exponential function.


Both are proportional to the square root of a simple number:

l \sim \sqrt{D \tau}

… the factor of proportionality being ‘small’ on a logarithmic scale, like π or 2 or their inverse. τ is the period, and D was a number expressing how well the material carries away heat energy.

There is another ‘simple’ scenario that also results in a length scale described by
\sqrt{D \tau} times a small number: If you deposit a confined ‘lump of heat’, a ‘point heat’ it will peter out and the average width of the lump after some time τ is about this length as well.

Heat eqn

Using very short laser pulse to heat solid material is very close to depositing ‘point heat’. Decades ago I worked with pulsed excimer lasers, used for ablation (‘shooting off) material from ceramic targets.This type of lasers is used in eye surgery today:

Hindsight is 20-20, Warfighter Refractive Eye Surgery Center has a vision of the future 141210-A-FJ979-002Heat is deposited in nanosecond pulses, and the run-out length of the heat peak in the material is about \sqrt{D \tau} with tau being equal to the very short laser’s pulse length of several nanoseconds. As the pulse duration is short, the penetration depth is short as well, and tissue is ‘cut’ precisely without heating much of the underlying material.

So this type of \sqrt{D \tau} length is not just a result of a calculation for a specific scenario, but it rather seems to encompass important characteristics of heat conduction as such.

The unit of D is area over time, m2/s. If you accept the heat equation as a starting point, analysing the dimensions involved by counting x and t you see that D has to contain two powers of x and one of t. Half of applied physics and engineering is about getting units right.

But I pretend I don’t even know the heat equation and ‘visualize’ heat transport in this way: ‘Something’ – like heat energy – is concentrated in space and closely peters out. The spreading out is faster, the more concentrated it is. A thin needle-like peak quickly becomes a rounded hill, and then is flattened gradually. Concentration in space means curvature. The smaller the space occupied by the lump of heat is, the smaller its radius, the higher its curvature as curvature is the inverse of the radius of a tangential circular path.

I want to relate curvature to the change with time. Change in time has to be measured in units including the inverse of time, curvature is the inverse of space. Equating those, you have to come with something including the square of spatial dimension and one temporal dimension – something like D [m2/s].

How to get a characteristic length from this? D has to be multiplied by a characteristic time, and then we need to take a the square root. So we need to put in some characteristic time, that’s a property of the specific system investigated and not of the equation – like the yearly period or the laser pulse. And the resulting length is exactly that l \sim \sqrt{D \tau} that shows up in any of of the solutions for specific scenarios.


Further reading:

The characteristic width of the spreading lump of heat is visible in the so-called Green’s functions. These functions described a system’s response to a ‘source’ which resemble a needle-like peak in time. In this case it is a Gaussian functions with a ‘width’ \sim \sqrt{D \tau} . See e.g. equation (14) on PDF-page 14 of these lecture notes.

Penetration depth of excimer lasers in human tissue – in this book the square root D times tau formula is used and depths are calculated to be equal to several 10 micrometers.