# Earth, Air, Water, and Ice.

In my attempts at Ice Storage Heat Source popularization I have been facing one big challenge: How can you – succinctly, using pictures – answer questions like:

How much energy does the collector harvest?

or

What’s the contribution of ground?

or

Why do you need a collector if the monthly performance factor just drops a bit when you turned it off during the Ice Storage Challenge?

The short answer is that the collector (if properly sized in relation to tank and heat pump) provides for about 75% of the ambient energy needed by the heat pump in an average year. Before the ‘Challenge’ in 2015 performance did not drop because the energy in the tank had been filled up to the brim by the collector before. So the collector is not a nice add-on but an essential part of the heat source. The tank is needed to buffer energy for colder periods; otherwise the system would operate like an air heat pump without any storage.

I am calling Data Kraken for help to give me more diagrams.

There are two kinds of energy balances:

1) From the volume of ice and tank temperature the energy still stored in the tank can be calculated. Our tank ‘contains’ about 2.300 kWh of energy when ‘full’. Stored energy changes …

• … because energy is extracted from the tank or released to it via the heat exchanger pipes traversing it.
• … and because heat is exchanged with the surrounding ground through the walls and the floor of the tank.

Thus the contribution of ground can be determined by:

Change of stored energy(Ice, Water) =
Energy over ribbed pipe heat exchanger + Energy exchanged with ground

2) On the other hand, three heat exchangers are serially connected in the brine circuit: The heat pump’s evaporator, the solar air collector, and the heat exchanger in the tank. .

Both of these energy balances are shown in this diagram (The direction of arrows indicates energy > 0):

The heat pump is using a combined heat source, made up of tank and collector, so …

Ambient Energy for Heat Pump = -(Collector Energy) + Tank Energy

The following diagrams show data for the season containing the Ice Storage Challenge:

From September to January more and more ambient energy is needed – but also the contribution of the collector increases! The longer the collector is on in parallel with the heat pump, the more energy can be harvested from air (as the temperature difference between air and brine is increased).

As long as there is no ice the temperature of the tank and the brine inlet temperature follow air temperature approximately. But if air temperature drops quickly (e.g. at the end of November 2014), the tank is still rather warm in relation to air and the collector cannot harvest much. Then the energy stored in the tank drops and energy starts to flow from ground to the tank.

On Jan 10 an anomalous peak in collector energy is visible: Warm winter storm Felix gave us a record harvest exceeding the energy needed by the heat pump! In addition to high ambient temperatures and convection (wind) the tank temperature remained low while energy was used for melting ice.

On February 1, we turned off the collector – and now the stored energy started to decline. Since the collector energy in February is zero, the energy transferred via the heat exchanger is equal to the ambient energy used by the heat pump. Ground provided for about 1/3 of the ambient energy. Near the end of the Ice Storage Challenge (mid of March) the contribution of ground was increasing while the contribution of latent energy became smaller and smaller: Ice hardly grew anymore, allegedly after the ice cube has ‘touched ground’.

Mid of March the collector was turned on again: Again (as during the Felix episode) harvest is high because the tank remains at 0°C. The energy stored in the tank is replenished quickly. Heat transfer with ground is rather small, and thus the heat exchanger energy is about equal to the change in energy stored.

At the beginning of May, we switched to summer mode: The collector is turned off (by the control system) to keep tank temperature at 8°C as long as possible. This temperature is a trade-off between optimizing heat pump performance and keeping some energy for passive cooling. The energy available for cooling is reduced by the slow flow of heat from ground to the tank.

# Frozen Herbs and Latent Energy Storage

… having studied one subject, we immediately have a great deal of direct and precise knowledge … of another.

Feynman referred to different phenomena that can be described by equations of the same appearance: Learning how to calculate the distribution of electrical charges gives you the skills to simulate also the flow of heat.

But I extend this to even more down-to-earth analogies – such as the design of a carton of frozen herbs resembling our water-tight underground tank.

No, just being a container for frozen stuff is too obvious a connection!

Maybe it is the reclosable lid covering part of the top surface?

No, too obvious again!

Or it is the intriguing ice structures that grow on the surface: in opened frozen herb boxes long forgotten in the refrigerator – or on a gigantic ice cube in your tank:

The box of herbs only reveals its secret when dismantled carefully. The Chief Engineer minimizes its volume as a dedicated waste separating citizen:

… not just tramping it down (… although that sometimes helps if some sensors do not co-operate).

He removes the flaps glued to the corners:

And there is was, plain plane and simple:

The Chief Engineer had used exactly this folding technique to cover the walls and floor of the former root cellar with a single piece of pond liner – avoiding to cut and glue the plastic sheet.

# My Data Kraken – a Shapeshifter

I wonder if Data Kraken is only used by German speakers who translate our hackneyed Datenkrake – is it a word like eigenvector?

Anyway, I need this animal metaphor, despite this post is not about facebook or Google. It’s about my personal Data Kraken – which is a true shapeshifter like all octopuses are:

(… because they are spineless, but I don’t want to over-interpret the metaphor…)

Data Kraken’s shapeability is a blessing, given ongoing challenges:

When the Chief Engineer is fighting with other intimidating life-forms in our habitat, he focuses on survival first and foremost … and sometimes he forgets to inform the Chief Science Officer about fundamental changes to our landscape of sensors. Then Data Kraken has to be trained again to learn how to detect if the heat pump is on or off in a specific timeslot. Use the signal sent from control to the heat pump? Or to the brine pump? Or better use brine flow and temperature difference?

It might seem like a dull and tedious exercise to calculate ‘averages’ and other performance indicators that require only very simple arithmetics. But with the exception of room or ambient temperature most of the ‘averages’ just make sense if some condition is met, like: The heating water inlet temperature should only be calculated when the heating circuit pump is on. But the temperature of the cold water, when the same floor loops are used for cooling in summer, should not be included in this average of ‘heating water temperature’. Above all, false sensor readings, like 0, NULL or any value (like 999) a vendor chooses to indicate as an error, have to be excluded. And sometimes I rediscover eternal truths like the ratio of averages not being equal to the average of ratios.

The Chief Engineer is tinkering with new sensors all the time: In parallel to using the old & robust analog sensor for measuring the water level in the tank…

… a multitude of level sensors was evaluated …

… until finally Mr. Bubble won the casting …

… and the surface level is now measured via the pressure increasing linearly with depth. For the Big Data Department this means to add some new fields to the Kraken database, calculate new averages … and to smoothly transition from the volume of ice calculated from ruler readings to the new values.

Change is the only constant in the universe, paraphrasing Heraclitus [*]. Sensors morph in purpose: The heating circuit, formerly known (to the control unit) as the radiator circuit became a new wall heating circuit, and the radiator circuit was virtually reborn as a new circuit.

I am also guilty of adding new tentacles all the time, too, herding a zoo of meters added in 2015, each of them adding a new log file, containing data taken at different points of time in different intervals. This year I let Kraken put tentacles into the heat pump:

But the most challenging data source to integrate is the most unassuming source of logging data: The small list of the data that The Chief Engineer had recorded manually until recently (until the advent of Miss Pi CAN Sniffer and Mr Bubble). Reason: He had refused to take data at exactly 00:00:00 every single day, so learned things I never wanted to know about SQL programming languages to deal with the odd time intervals.

To be fair, the Chief Engineer has been dedicated at data recording! He never shunned true challenges, like a legendary white-out in our garden, at the time when measuring ground temperatures was not automated yet:

Long-term readers of this blog know that ‘elkement’ stands for a combination of nerd and luddite, so I try to merge a dinosaur scripting approach with real-world global AI Data Krakens’ wildest dream: I wrote scripts that create scripts that create scripts [[[…]]] that were based on a small proto-Kraken – a nice-to-use documentation database containing the history of sensors and calculations.

The mutated Kraken is able to eat all kinds of log files, including clients’ ones, and above all, it can be cloned easily.

I’ve added all the images and anecdotes to justify why an unpretentious user interface like the following is my true Christmas present to myself – ‘easily clickable’ calculated performance data for days, months, years, and heating seasons.

… and diagrams that can be changed automatically, by selecting interesting parameters and time frames:

The major overhaul of Data Kraken turned out to be prescient as a seemingly innocuous firmware upgrade just changed not only log file naming conventions and publication scheduled but also shuffled all the fields in log files. My Data Kraken has to be capable to rebuild the SQL database from scratch, based on a documentation of those ever changing fields and the raw log files.

_________________________________

[*] It was hard to find the true original quote for that, as the internet is cluttered with change management coaches using that quote, and Heraclitus speaks to us only through secondary sources. But anyway, what this philosophy website says about Heraclitus applies very well to my Data Kraken:

The exact interpretation of these doctrines is controversial, as is the inference often drawn from this theory that in the world as Heraclitus conceives it contradictory propositions must be true.

In my world, I also need to deal with intriguing ambiguity!

# And Now for Something Completely Different: Rotation Heat Pump!

Heat pumps for space heating are all very similar: Refrigerant evaporates, pressure is increased by a scroll compressor, refrigerant condenses, pressure is reduced in an expansion value. *yawn*

The question is:

Can a compression heat pump be built in a completely different way?

Austrian start-up ECOP did it: They  invented the so-called Rotation Heat Pump.

It does not have a classical compressor, and the ‘refrigerant’ does not undergo a phase transition. A pressure gradient is created by centrifugal forces: The whole system rotates, including the high-pressure (heat sink) and low-pressure (source) heat exchanger. The low pressure part of the system is positioned closer to the center of the rotation axis, and heat sink and heat source are connected at the axis (using heating water). The system rotates at up to 1800 rounds per minute.

A mixture of noble gases is used in a Joule (Brayton) process, driven in a cycle by a ventilator. Gas is compressed and thus heated up; then it is cooled at constant pressure and energy is released to the heat sink. After expanding the gas, it is heated up again at low pressure by the heat source.

In the textbook Joule cycle, a turbine and a compressor share a common axis: The energy released by the turbine is used to drive the compressor. This is essential, as compression and expansion energies are of the same order of magnitude, and both are considerably larger than the net energy difference – the actual input energy.

In contrast to that, a classical compression heat pump uses a refrigerant that is condensed while releasing heat and then evaporated again at low pressure. There is no mini-turbine to reduce the pressure but only an expansion valve, as there is not much energy to gain.

This explains why the Rotation Heat Pumps absolutely have to have compression efficiencies of nearly 100%, compared to, say, 85% efficiency of a scroll compressor in heat pump used for space heating:

Some numbers for a Joule process (from this German ECOP paper): On expansion of the gas 1200kW are gained, but 1300kW are needed for compression – if there would be no losses at all. So the net input power is 100kW. But if the efficiency of the compression is reduced from 100% to 80% about 1600kW are needed and thus a net input power of 500kW – five times the power compared to the ideal compressor! The coefficient of performance would plummet from 10 to 2,3.

I believe these challenging requirements are why Rotation Heat Pumps are ‘large’ and built for industrial processes. In addition to the high COP, this heat pump is also very versatile: Since there are no phase transitions, you can pick your favorite corner of the thermodynamic state diagram at will: This heat pump works for very different combinations temperatures of the hot target and the cold source.

# 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.

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:

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:

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     |
|------------|                 |-----------------|
|
v
|
|----------------------------------------------------------|
|        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    |
|------------|                 |---------------|
|
v
|
|----------------------------------------------------------|
|        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:

$\frac{1}{\eta_\text{engine}}\geq\varepsilon_\text{heatpump}$

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:

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

… 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}$

and

$\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:

$\frac{1}{\eta_\text{engine}}\geq\frac{1}{\eta_\text{carnot}}\geq\varepsilon_\text{heatpump}\geq1$

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.

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 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:

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.

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 …

Typical, temporary nerd’s test setup.

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

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 control unit from Technische Alternative (each connected to a different CAN bus).

Bringing up the interface

According to messpunkt.org 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.

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)

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)
0010:  0050  (GERAETEKONFIGURATION  80)
0013:  01e0  (EINSTELL_SPEICHERSOLLTEMP  48.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)
092f:  0006  (WAERMEERTRAG_HEIZ_TAG_KWH  6)
/* 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 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:

0016 RUECKLAUFISTTEMP
01d4 QUELLE_IST
01d6 WPVORLAUFIST
091b EL_AUFNAHMELEISTUNG_WW_TAG_KWH
091d EL_AUFNAHMELEISTUNG_WW_SUM_MWH
091f EL_AUFNAHMELEISTUNG_HEIZ_TAG_KWH
0921 EL_AUFNAHMELEISTUNG_HEIZ_SUM_MWH
092b WAERMEERTRAG_WW_TAG_KWH
092f WAERMEERTRAG_HEIZ_TAG_KWH
092d WAERMEERTRAG_WW_SUM_MWH
0931 WAERMEERTRAG_HEIZ_SUM_MWH
000c AUSSENTEMP
0923 WAERMEERTRAG_2WE_WW_TAG_KWH
0925 WAERMEERTRAG_2WE_WW_SUM_MWH
0927 WAERMEERTRAG_2WE_HEIZ_TAG_KWH
0929 WAERMEERTRAG_2WE_HEIZ_SUM_MWH

Script:

# Define folders
logdir="/CAN_LOGS"
scriptsdir="/CAN_SCRIPTS"
indexfile="$scriptsdir/indices" # FTP parameters ftphost="FTP_SERVER" ftpuser="FTP_USER" ftppw="***********" # Exit if scripts not found if ! [ -d$scriptsdir ]
then
echo Directory $scriptsdir does not exist! exit 1 fi # Create log dir if it does not exist yet if ! [ -d$logdir ]
then
mkdir $logdir fi sleep 5 echo ====================================================================== # Start logging while [ 0 -le 1 ] do # Get current date and start new logging line now=$(date +'%Y-%m-%d;%H:%M:%S')
line=$now year=$(date +'%Y')
month=$(date +'%m') logfile=$year-$month-can-log-wpf7.csv logfilepath=$logdir/$logfile # Create a new file for every month, write header line # Create a new file for every month if ! [ -f$logfilepath ]
then
do
header=$(echo$indexline | cut -d" " -f2)
headers+=";"$header done <$indexfile ; echo "$headers" >$logfilepath
fi

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

# Loop through interesting Elster indices
do
# 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
line="$line;$value"
done < $indexfile ; echo$line >> $logfilepath # echo FTP log file to server ftp -n -v$ftphost << END_SCRIPT
ascii
user $ftpuser$ftppw
binary
cd RPi
ls
lcd $logdir put$logfile
ls
bye
END_SCRIPT

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

# Wait - next logging data point
sleep 180

# Runs forever, use Ctrl+C to stop
done


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.