Solar into heaters. A year later.

pascal boudalier
7 min readFeb 24, 2024

A year ago, I wrote a Python application to redirect excess solar into my home’s existing electric heaters.

This has been (I am proud to say) working like a charm and delivering on the promises: no energy fed to the grid, every bit used to warm my home.

Like a charm? Really? In fact yes, but only according to the initial specifications.

After a year of operation, it is time to reflect, understand what I overlooked , what can be optimized, and finally to quantify monetary benefits.

The updated application is available on github

What did I not totally thought thru ?

The initial idea was to make sure that when I am away from home, every bit of excess solar energy would go toward heating my home instead of feeding the grid for free.

So the automation logic goes about “taking control” of some of my house’s electric heaters, and turning them on whenever there is excess solar.

.. and turning them off when there is none .

Wait.. turning them off … this is fine if I am away. But if I am in my house, and it is winter and cold, I want my heaters on, even if there is not solar.

I do not want the automation to fight me or , to be more accurate, to fight my daughter: she turns the heater on, the automation later comes up and say “ Hey, there is no excess solar so let’s turn this heater off” … then she is pissed…

I also need to cover some seasonal aspects. Do I really want to heat my house with excess solar during summer’s heat wave?

So let’s tune the whole thing, and what is better for this exercise than a 3x2 matrix ?

I realized that disabling the automation raises the question of whether the automation must turn the heaters off or leave them as they are. This behavior is now configurable.

  • Leave the heaters alone: for example, it is winter time, I come in the house and turn the heaters on. Then, I realize the automation is fighting me, so I disable it but I do not want the automation to turn the heaters off and would rather have them left as they are. See the arrow A above.
  • Turn the heaters off: for example, it is spring time and I want the surplus to go to my EV instead of the heaters. I therefore disable the automation, but this time I want the automation to also turn the heaters off, to make the surplus available to the EV charger. See the arrow B above.

The simplest possible UI

The smartphone's GUI has a button to enable or disable automation. However, can we think of a simpler UI? A UI for everyone in the house

Yes. A button.

I mean a physical button. This thing in white plastic:

A very handy module (Shelly i3) fits right on the back of a physical switch. This module can be programmed to send URLs based on the switch position. Those URLs are served by a web server in the solar2heater application, which can enable/disable automation.

Now automation can also be controlled with the flip of a switch!

Note that the application is able to report whether the automation was enabled/disabled by the GUI or by the manual switch.

Server consolidation

A very popular theme for the IT industry in the 2000’s. Now even relevant for home servers.

The first version of the Solar2heater app was running on a dedicated Raspberry PI3. But the less Raspberries, the less headaches (update, backup, etc. )

Consequently, the application now runs on my home server Raspberry PI4 (already running a bunch of my stuff, such as a NAS, a private cloud, a VPN, an adblocker, a photo gallery, a camera server ..etc.)

Because Solar2heater needs to access a PZEM-004, a change is necessary to measure the amount of power being diverted by the solar router because the PI4 and the PZEM are now in different locations.

This new configuration is implemented as a client server model, where the PI4 receives data (thru WiFi) from a remote ESP32 micro-controller connected to the PZEM (Once the firmware is flashed in the ESP32, it needs zero attention)

Both the client code (python/Raspberry PI) and the server code (MicroPython, ESP32) are available on github.

I am reusing this architecture in multiple applications, to get power information from various places of interest in my electrical installation.

Show me the money

I did not build this for money, but still , does it save any?

One has to be careful with the definition of “saving”. Putting energy in a heater (because the energy is “free”) , when I would not have redirected this energy before, is not really saving.

However, in the winter time, I have to consume energy to maintain the house at a minimum temperature for frost protection. This is managed automatically by the heaters themselves and runs whether there is solar or not.

Any solar used in that case replaces energy drawn from the grid and therefore generates actual dollar saving (in my case, euros).

OK, what about this graph

This very interesting graph (from Enphase, the brand of my microinverters) gives me some hints.

One week of solar production and house consumption.

The blue line represents the solar production over a week where I was mostly away from home. The orange line represents the total house consumption over that period (the Y axis is the Power expressed in Watt).

  • The blue line is solar production. The peak power is ~4Kw and the production happens (obviously) during the day.
  • The orange line is the total electrical power consumed by the house. When the orange line is “above” the blue line, the house is consuming electricity from the grid.
  • On Jan 30th, the orange line is largely above the blue one, because I was home, recharging the EV (partly on solar, partly on grid).

Beside Jan 30th, as I am staying away, the house is in the state I described earlier: it maintains the temperature at a minimum level for frost protection, drawing from grid only when necessary.

  • During those days, when there is solar, the orange line nicely tracks the blue one, meaning the automation logic does its job, making sure the house consumes all solar production (in the heaters) and only solar production.
  • During the nights, there is still consumption going on (the orange line is not zero). This represents the grid energy needed to maintain the house’s temperature at a minimum.
  • The interesting bit is that the consumption level is not the same at sunrise and at sunset. It is lower at sunset, because the house has already been heated during the day with solar. In a way the solar energy from the day has been stored as thermal energy, and there is less need for grid energy to maintain the temperature.
  • As the night passes, this stored thermal energy dissipates, and the grid takes over (the orange curve ramps up during the nights)… until solar hits again

If there were no solar, we can assume that the power consumed at sunset would keep increasing, or at least stay flat during the night (there is no reason for it to drop materially, because where would the energy comes from ?).

Actually, looking at Jan 31th, Feb 1th, we see the orange curve kind of flattening. This seems to be the equilibrium, i.e. the amount of power needed to maintain minimum temperature.

So without solar, we can estimate that the orange line would roughly stay flat from sunset to sunrise, at the level we observe at sunset.

This is too long, do show me the money!

Ok, Ok .. we are almost there.

As first approximation, the area of the blue shapes below represents the grid energy being saved because all solar energy was stored as thermal energy.

In other words, the saved energy is the energy that , otherwise, would have been drawn from the grid, from sunset to sunrise.

This is a lower-end estimate, as there is saving during solar production, but this is an order of magnitude analysis.

A bit of Euclidean geometry later:

  • sunset: 17h , power ~600W
  • sunrise: 8h, power ~1300W
  • (1300–600) * 15 / 2 ~ 5000, i.e. 5Kwh

In France, this translates into a bit more than 1 euro.

Another day, another euro.

See you in one year !! We will talk about home battery and heat pump: two other candidates for excess solar consumption.

--

--

pascal boudalier

Tinkering with Raspberry PI, ESP32, RiscV, Solar, LifePo4, IoT, Zigbee, energy harvesting, Python, MicroPython, Keras, Tensorflow, tflite, TPU. Ex Intel and HP