For some time now my Home Energy Management System (HEMS) has been managing many of my domestic electricity consumers including:

• car charging
• dishwasher
• home storage battery
• washing machine
• water heating via immersion heater

The overarching strategy has been to:

• maximise use of my own solar energy (rather than consume from the grid)
• prioritise consumers for best value within the constraint of available solar generation
• when power is needed from the grid to optimise the purchase price by shifting consumption to the cheapest periods (my price changes every half an hour)

For some consumers such as car charging and water heating this has resulted in those consumers switching between two modes:

1. self-consumption when they are enabled to use the ‘free’ electricity from my own solar panels (subject to device prioritisation) with some proportional control
2. boost when they run at full power drawing some if not all of the required power from the grid at the lowest available price

However the quite exceptional stress being put on the grid in the UK has prompted some expansion of capability. It’s normal once in a while that my electricity prices go negative, commonly caused by the overlap of large amounts of renewable electricity on the grid (e.g. excess solar output on sunny afternoons and/or high windfarm output due to wind conditions) and low demand (summer nights without heating demand, summer afternoons, bank holidays etc) which is exacerbated by the current corona situation. The current corona situation has made this more common and the plunge pricing events more extreme with multiple hours of negative pricing today some of which are into double digits (which I think is unprecedented). For car charging and water heating this has resulted in a new control mode.

• 

• 

The new control mode is a disabled status where the the device neither self-consumes nor is forced on. In the short term this increases export to the grid, but the mode is intended to help balance the grid disabling consumption for now to enable more consumption when the grid is under most extreme stress from an excess of generation over demand. Or to think of it another way, it passes up the opportunity to use free electricity now in order to be paid to use electricity later, responding to the price incentive to support balancing the grid.

Thus on a normal day these devices switch half-hourly between self-consumption (free electricity) and Boost (paid for electricity), but on a price plunge day then they switch half hourly between the new disabled state (no electricity, increased export) and the existing Boost (but now paid-to-consume electricity).

The full availability of modes is thus:

mode / other	abbreviation	battery storage	car charger	water heating
Make and model		Powervault G200	N/A	Immersun v2
Control means		API	Relay	Mixed API and relay
Mode – Boost	++	Powervault “Force charge”	via HEMS relay (Ch 1)	Via HEMs relay (Ch 2) to Immersun “External Boost” input.
Mode – Self-consumption only	+	Priority #1 Powervault “Charge only”	Priority #2 via Immersun relay output (Ch 3)	Priority #3 Immersun default behaviour
Mode -Disabled	0	N/A – Available in API but not used by HEMS.	via HEMS relay (Ch 4)	Immersun “Holiday” mode via API
Mode – Both self-consumption and self-discharge available	+/-	Powervault “Normal” via API	N/A – No reverse flow from car to home available (not V2X capable)	N/A

We should thus be better equipped to support the grid in the current circumstances.

The chart above shows the resulting behaviour. In particular the large negative currents through the morning to early afternoon show that much of the normal self-consumption has been disabled. Then from mid-afternoon the import shows the effect of enabling multiple consumers simultaneously. Here the behaviour of the car charging and water heating was boosted as this point, while the dishwasher’s and washing machine’s existing behaviour added to load.

Not that it has anything to do with the revised controls, but the spikiness of the export during the day shows the highly variable nature of the export through the day being a function of both variable generation through passing clouds and variable consumption with kettle boils and the like. Thus it’s important that consumers for self-consumption have automated closed loop control since manual control of an immersion heater or car charger to achieve high self-consumption with minimal import would have been almost impossible even with a level of human intervention wholly at odds with the scale of savings achieved – small savings hour-by-hour add up over the day, weeks and months but their value is relatively tiny compared to the labour to attempt equivalent control manually.

Here is a similar import-only half-hourly view from the smart meter WAN side:

The screenshot above clearly shows those periods of import being targeted at the periods with the most negative prices. Since different consumers need power for different periods of time (for example it takes about 7 hours to charge the battery, but only 2 or 3 for a tank of hot water) then consumption rises as cost falls. My consumption-weighted average cost was -6.22 p/kWh yesterday. However the same price point during the day or night has delivered different consumption from the grid as the output of the solar panels must be consumed before consumption from the grid starts. We are still some way from the point where it becomes economically attractive to disable the solar panels.

Finally the above image shows the last 28 days of electricity average cost in p/kWh. Although some other days included some periods of negative pricing, the quite exceptional pricing yesterday is amply illustrated with the combination of extreme prices and the new load management mode delivering revenue (i.e. negative cost) of 82.4 pence through consumption of 13.252 kWh at an average 6.22 p/kWh.

This is something of a zero sum game in terms of consumption as I don’t artificially increase consumption to improve income – such as leaving the oven on with the door open during a summer day – this is all about shifting consumption that would have happened anyway. However we have not only supported the grid when it is most stressed but also reduced our energy costs significantly (to the point of being significantly negative) by moving consumption from being predominately self-consumption (i.e. from our own solar panels) to being predominantly grid consumption.

As regular readers will recall I’ve recently updated my battery controls with solar predication. For some years now my battery storage has automatically charged during sunshine and later discharged in the evening, and over the last year I added the HEMS to manage buying electricity including for the battery when the electricity cost was cheapest as there’s little solar in the winter, but now the HEMS has the ability to automatically adjust how much power is bought from the grid depending on how much output is expected from the solar panels in order to deliver a charged battery by the end of the day when the electricity price rises significantly. The battery charging can thus swing from all solar to all grid and all points in between entirely automatically based on the solar forecast.

Now however I’ve also added the capability to adjust when the wet goods – dishwasher and washing machine – run as a function of expected solar panel output.

• 

• 

As with the battery controls, I don’t attempt to match generation half hour by half hour with device operation because of uncertainty around how precisely a solar forecast from the evening before will match actual solar production up to twelve hours later. Instead my solar algorithm extracts the number of hours of significant solar production and the earliest start time of that production. For the battery that information is used to modify the number of hours of battery charging to be bought from the grid and the end of the window during which those hours of charging may be bought. Now I’ve updated the controls for the wet goods similarly.

The existing wet good controls look to start the machine at the time when the electricity cost for the cycle is cheapest within a time window set by the user, so the user defines the earliest and latest acceptable start times and the algorithm finds the cheapest start time within that window. The updated wet goods controls assess the number of hours of solar charging available and if both (i) the window exceeds a certain size and (ii) the user’s time window includes the solar window then the user window is narrowed to start at the start of the solar window. The resulting start time between the start of the solar window and the end of the user window may not be absolutely the cheapest grid cost but my assumption is that the solar contribution (which could be up to 100%) will in practice make this the cheapest grid cost as any power needed from the grid will be at a relatively good price. If this start time in the solar window does not reflect absolutely the cheapest grid cost then a second start time may also be identified which is the cheapest grid cost.

In the above example the start times are both within the solar window and the cheapest energy price, so no cheaper alternative is also offered. Start times within the solar window tend to be in the afternoon as the grid energy costs are lower. This also improves the probability that the battery may briefly discharge if the total load exceeds the solar output. However in the above example the energy price is so low that the battery is also force-charging (it’s dark green) so any surplus demand will come from the grid.

In the above example the cheapest time to run each cycle from the grid is at night, although given the availability of solar during the day then any small saving in grid costs at night is very likely wiped out by the ability to run some (if not all) of the cycle during the day from the solar surplus rather than the grid. Both start times are available – the absolutely lowest grid cost and the lowest grid cost during the solar window.

It’s probably also worth mentioning the implications of running the appliance alongside the battery status being different colours:

• Blue battery and state of charge being at or over 80% – appliance is prioritised over battery allowing battery to discharge to meet appliance needs as required – least likely to draw anything from grid (but likely highest cost to draw from grid)
• Light green battery or (blue battery and state of charge being below 80%) – appliance is prioritised over battery charging alone (so battery may not discharge to support appliance) – a little more likely to draw anything from grid (but likely mid cost to draw from grid)
• Dark green battery – battery charging and appliance are equal priority – most likely to draw something from grid (but likely cheapest cost to draw from grid, even to the point of being paid to draw from grid at times)

Last night rather unexpectedly my solcast solar irradiance data tuned itself. I use this data to predict the output of my solar panels and adjust what I buy from the grid in response. I had expected that tuning would happen eventually, but my understanding was that two month’s data was required, not the two week’s data that I had so far supplied.

Prior to tuning my predictions had looked like this..

Although the system is clearly predicting output to a reasonable degree of accuracy, there are two obvious issues:

1. The orientation of the array from due south seems a little off, as my array starts and ends generation earlier than the prediction suggesting the the orientation should be slightly more easterly in the model.
2. The peak at a sustained 4 kW is overly optimistic. The panels can generate 4 kW according to my monitoring, but only relatively briefly and certainly not for more than an hour in March.

Nevertheless, the overall identification of better and worse days is clearly working.

However after tuning both issues have been resolved. The measured and predicted curves match very closely. Note that the prior predictions have been updated by the tuning process, so March 26th which is included in both the images looks subtly different. Note also that my control is based on forecasts from the evening before, not the ‘1 hour ahead forecasts’ illustrated above. You may also observe that there is a discrepancy in the morning of April first, where the measured data is zero while the estimated actuals and forecasts are quite healthy, which arises as a result of a temporary failure of the immersun server from where the data is taken.

The ability to do tuning requires an upload of data. I upload generation data continuously at 5-minute intervals (the shortest allowed interval) which may explain the early availability of the tuned results. The script that I use to achieve this takes data indirectly from my ImmerSUN and is modified from this script. I achieved a 99% correlation which is pretty good. Subsequently it seems that the tuning takes place automatically each day.