This project is my Hello World onboard the Arduino, and 10 years have passed since my last programming effort, so please be forgiving about the quality of my coding.
Here’s the scenario:
- I own a house.
- I installed a grid connected photovoltaic system.
- I bought a modern domestic hot water (“DHW”) heat pump boiler.
I could let the boiler do its job, and a hot shower but poor self-consumption would be the result.
I could connect the boiler to the PV system through a wattmeter driven relay. This would raise my self-consumption (i.e. free hot water), but sometimes the sun won’t be enough so an occasional cold shower is to be expected.
I could use natural gas as a heat backup for such occasions, but my PV has plenty of electricity available through net-metering, and avoiding natural gas usage was and still is my main goal.
There are plenty of Arduino projects that provide electricity measurement and logging, and the vast majority of DHW boilers can read an external dry contact acting as “call for heat”, so a relay shield could do the job.
I chose… neither of these approaches.
I began by logging the electricity usage of a stardard family for a complete year with a commercial datalogger, I’m talking a family with both a PV system of at least 3 kWp and a heat pump DHW boiler of at least 250 lt. .
I collected as many as 2.5 million records per family, and did this with 3 different real world families of 2, 3 and 4 people.
Then I managed to set up humongous nighttime simulation sessions looking for a way to optimize the warm up cycles of the boiler according to BOTH the self-consumption ratio AND the minimum level of service needed.
Here’s what I found.
First of all, when there is enough excess energy, the heat pump should turn on. A good threshold should never exceed boiler consumption, so far so good.
Now, since we are heating for the evening and the following morning, the threshold should slowly decrease as we approach the evening but of course go up again when the evening begins.
It may sound too easy, but this “decreasing threshold” got the job done pretty well in all my simulated scenarios.
Of course, this is true provided we find a clever way to evaluate the threshold decrease rate in real time.
So, our energy balance will repeatedly be triggered against our threshold, decreased by an escalation factor.
This guy will be something like N watts/minute from XX:XX in the morning to YY:YY in the evening.
Escalation will be based on expected PV production, weather forecast for the next hour and water temperature gradient expected, i.e. desired temp minus actual temp. We can’t predict any household appliance, so let’s move on.
Expected PV production (i.e. season factor) deals with solstices and equinoxes, with a fixed 31 days of global thermal inertia (trust me on this). Southern emisphere inhabitants may want to fix this one.
Weather forecast (i.e. weather factor) is gathered via Multicast once every 40 minutes.
The reason for these two is quite easy to understand:
- Little excess energy in a sunny midday of July? Who cares! There’s plenty of time for heating, let the washing machine finish its job!
- No excess energy in a snowy midday of January? Go go go! It won’t get any better today!
The real time threshold on the other hand, is represented by an average consumption (see tech specs of your boiler) altered by these 2 factors:
- water temperature
- intake air temperature
We have to go by trial and errors for these. My own device is fine with 7 and 0 respectively.
This is to avoid turning the boiler on just to measure its energy consumption (heat pumps hate this behaviour).