We will shortly have been in this house for six years. During that time I have created three smart control systems that improve my energy costs or efficiency:
heating controls to minimise gas purchase
self-consumption controls of the electricity generated by my solar panels to maximise value of self-consumption
smart tariff controls to buy grid electricity at the lowest price
Most homes have a single heating zone with one timer and potentially one thermostat controlling the whole house with perhaps some thermostatic radiator valves (TRVs) capping the temperature in specific rooms.
By contrast we have seven heating zones created by electronic temperature control valves (eTRVs). Each zone has its own timer. There is no central timer or thermostat. Each eTRV can summon the boiler on when cold rather than simply cap the maximum temperature like a TRV.
Some rooms also have links to other smart devices such as disabling room heating when the window is open or turning off heating early when there’s no movement in the room.
The intent is to save energy by only heating rooms that are in use.
These controls manage the diversion of any excess output from my solar panels rather than give that energy to the grid. The loads are prioritised as follows:
Powervault storage battery (fully proportional)
Car charger (stepped proportional driven by ImmerSUN relay output)
Hot water (driven by ImmerSUN fully proportional output)
Last year these controls helped me to use over 90% of the output of my solar panels avoiding buying £100s of electricity and gas. The priorities are set to maximise value – #1 avoid daytime electricity use at 16 p/kWh, #2 avoid car charging at 5-16 p/kWh, and #3 avoid gas consumption at 2.96 p/kWh.
Smart Tariff Controls
These controls manage my electric devices for lowest grid energy cost. The controlled devices are:
Battery storage (Powervault)
Electric car charger
Hot water heating (ImmerSUN)
The hardware that has this control is known as a Home Energy Management System (HEMS). My HEMS is based on a simple computer known as a Raspberry Pi. The HEMS uses foreknowledge of the electricity price and predicted solar panel output to determine when best to run the above devices. It was designed around a tariff called Octopus Agile which has 48 half-hourly prices that change daily, but is currently working with a simpler two-rate smart tariff.
Central Heating Boiler
Electric car charger
Hot water heating
Devices controlled by smart systems
Most of these solutions are made up of commercially-available items that I have perhaps combined in a way not anticipated by their manufacturers. In particular:
I created a relay module to enable the gas boiler to be turned on remotely and programmed a series of logical rules for the Apple TV’s that act as the controllers.
I identified a way to prioritise different self-consumption devices by configuring their current clamps.
I built my smart car charger integrating various items of hardware and writing the ladder logic program that runs it.
I built the HEMS from commercially-available parts and wrote the software that runs on it to control my devices.
For the last few years I’ve been a user of, and advocate for, Octopus Energy’s Agile tariff. This unique tariff in the UK is linked to half-hourly wholesale electricity prices and gives the user 48 half-hourly electricity prices each day. As the price of electricity varies considerably from one half hour to another, customers like myself could save quite a lot of money by shifting consumption around such as by charging the car or running the washing machine at different times.
However in recent months wholesale electricity prices have been high. My understanding is that this is from a combination of factors including aging power stations being offline for maintenance and Brexit-related issues around market access and trading. The result of this is that while there’s still variation by time of day in the wholesale markets the pricing is always relatively high. The Agile tariff also applies a multiplier to the market prices to cover Octopus Energy’s costs which drives the retail price even higher. Thus there really doesn’t seem to be a financial benefit to such extreme agility compared to some more conventional tariffs. (I’m not criticising Octopus Energy here – they are completely transparent about how this tariff works)
As a result of this a few days ago I switched to another Octopus tariff – Go. Go is more like a traditional time-of-use tariff – like Economy 7 in the UK – except that Go provides a shorter cheap window of 4 hours not 7 hours and a deeper discount. Go’s headline pricing is a cheap 5p/kWh from 00:30 to 04:30 with a higher standard rate that varies by region and gets adjusted from time to time. My standard rate is 15.96 p/kWh fixed for 12 months.
My electricity consumption is managed by the Home Energy Management System (HEMS) which has been optimising my energy costs for some two and a half years. Having decided to move away from Agile then I need a quick change for my HEMS to work with the new Go tariff. My quick solution (a whole two lines of code) is to edit the Agile costs on the fly each day to replace Agile costs with Go costs in the 4 cheap hours – a softy of hybrid of Agile and Go. Additionally I’ve used an existing configuration file to apply a price cap at which the battery can be charged from the grid preventing grid charging above the 5 p/kWh price as it makes no economic sense to charge the battery at the higher Go price to avoid buying electricity at the same higher grid price. A side-effect of this (which I quite like) is that daytime consumption is still managed in a grid-friendly manner via the Agile price even though I’m physically paying the Go price. (I may have to think about this further if the Agile price starts to drop below 5 p/kWh)
The immediate effect of the standardised Go price at night is that the behaviour of the HEMS for EV charging, dishwasher, washing machine and water heating has all standardised too. All these now start at 00:30 except for water heating which now never happens from the grid since mains electricity is now always more expensive than gas. Dishwasher and washing machine may also be scheduled for during the day if anticipated solar production is high enough, while EV charging and water heating may also happen from solar in a closed loop manner.
Battery charging is a little less standardised at night. Battery charging now varies in a range of 0 to 4 hours overnight varying with anticipated solar production the next day. In the last few days I’ve seen both bookends – no hours of battery charging when the day ahead will be sunny and 4 hours of charging when the day ahead will be more mixed. During the cheap window, if the battery is not charging, then the battery is not permitted to discharge. Yesterday was one of the mixed days.
As can be seen from my smart meter data above, almost all the electricity consumed was at night in the cheap window, so my average electricity cost for the day will be very close to 5p/kWh.
The battery charging and discharging is shown by the blue and gold lines above. Initially the battery discharges to avoid paying 16 p/kWh to the grid, then it charges for 4 hours at 5 p/kWh, then there’s some further discharge until the sun rises, in the morning there’s some sun which charges the battery in a somewhat variable manner, then in the afternoon it’s sunnier and the battery reports some ‘Grid Power Out’ which is actually power available for lower priority self-consumption devices, and finally the battery discharges through the evening. There would have been some opportunity to charge the battery more during the afternoon but the battery was already nearly full.
The ImmerSUN gives probably the most complete overview of the home, albeit at only hourly resolution as follows:
Purple is the electricity consumption (home, battery, dishwasher, washing machine etc)
Red is bought electricity (58% of total)
Green is generated electricity (42% of total)
Blue is electricity used for water heating (which is all from generation and part of the 97% self-consumption)
Teal is electricity export (which is minimal at 3%)
In conclusion the change to Go seems to be saving me a significant amount of money compared to current Agile prices, and the hybridisation of the tariffs seems to be working well from a control perspective giving me the financial benefits of Go and should deliver the grid-friendly behaviour of Agile (although I’d need poorer weather to demonstrate that).
If you are a GB resident and would like to switch to Octopus Energy (who have incidentally been Which-recommended for years) then we can each earn £50 credit from this referral link.
It’s now around four and half years since I bought my Powervault G200 storage battery and two years since I started managing it from my Home Energy Management System (HEMS).
Originally the Powervault set up simply to store surplus electricity from my solar panels for later use but, following my change to Octopus’ Agile tariff, I started to use the Powervault to optimize electricity costs when there wasn’t going to be enough solar, charging when electricity was relatively cheap and discharging when electricity was relatively expensive. Initially I configured the Powervault manually to achieve this but later moved to the HEMS doing it automatically.
The fundamental principle has remained the same through both manual and automated periods, with the battery being set into one of three modes depending on price:
Force charge – where the battery charges at full power (usually from the grid) for the required number of hours – when grid electricity price is cheapest.
Only charge – when the battery charges proportionally to the solar surplus (but will not discharge) – when grid electricity is mid-price (i.e. too close to the price at which the battery was being force charged to be economically advantageous to discharge)
Normal – when the battery charges or discharges proportionately to the solar surplus/shortfall – when grid electricity is comparatively expensive compared to the force charge price.
The current logic now reflects electricity price, time of day and state of charge. The fundamental relationship is with grid electricity price as previously described, but with two further refinements:
During the day, even when the electricity price is relatively high, the battery is held in charge only until 80% state of charge is obtained. This helps ensure that a high state of charge is obtained before the early evening peak in Agile prices from 4 to 7 PM by not allowing the battery to discharge while the expectation is that it is being charged from solar. In the depths of winter, when the battery is more likely to be charged overnight and thus start the day with a high state of charge, the same logic allows the battery to discharge to 80% if electricity is costly during the day but still preserves charge for the early evening peak.
Similarly if the battery is full, but the grid price is medium, then the battery is also allowed to discharge to 95% during the day. This allows the battery to discharge slightly to cover small peaks of demand on the assumption that a small amount of solar recharge may well be possible even if the solar forecast wasn’t high enough for recharging at full power.
To consider the two bookends of behaviour:
On a really sunny day like tomorrow, the HEMS doesn’t anticipate any need to buy electricity from the grid for battery charging so all electricity is relatively expensive. The HEMS will allow the battery to discharge overnight (completely if necessary) . From 8:00 AM the battery will only be allowed to charge until 80% state of charge or 4:00 PM is reached after which the battery will be put back in Normal operation when it has the freedom to either charge or discharge.
On a winters day, the HEMS potentially fully charges the battery overnight. Between 8:00 AM and 4:00 PM the battery is allowed to discharge to 95% if grid electricity is mid-price (with some hope that the 5% may be recovered from solar), or to 80% if grid electricity is high price. After 4:00 PM the battery reverts to Normal operation for the evening peak period.
I’m very pleased with how robustly my battery integration operates. It is however reliant on the continuing availability of the Powervault G200 cloud which may not be around forever as the G200 model has now been superseded. My own example is currently four and a half years old.
Regular readers may recall that our hot water can be generated in 3 different ways: (i) conventional gas boiler, (ii) from grid electricity and (iii) from the surplus on my own solar panels. Attractions of these options are that gas is always available and stable in price, but my grid electricity is lower carbon and may at times be cheaper than gas, and my solar electricity is lowest in both carbon and cost but is subject to significant daily and seasonal variation.
The logic to sort out which source to use is managed by my HEMS. Gas is the baseline and the gas boiler is set to heat water for an hour a day in the early evening to ensure that baths etc are possible. The heating is thermostatically controlled so it doesn’t heat if the water is already hot, and that thermostat is set slightly lower than the immersion thermostat too.
The ImmerSUN normally operates automatically to divert surplus solar electricity proportionately to the immersion heater after the needs of general house load, battery charging and car charging have been taken. However if the electricity price is negative (yes, really) then the HEMS may override the ImmerSUN so that water heating is not done by free solar but instead may be delayed to allow use of paid-to-use electricity.
The final part of this triumvirate is buying electricity from the grid to heat water. Here the price of bought electricity is compared either to the price of gas and a decision made to use electricity when it is cheaper (it’s always lower CO2), or compared to the price of surplus solar (effectively zero) to buy from the grid. Both of these are obviously comparisons with a price threshold but until now the choice of threshold has been made manually – typically against gas in winter when solar output is limited and against solar in summer when more readily available. However the reality of UK weather is that this is a compromise as it may be very sunny one day but very dull the next.
The new refinement therefore is to use the existing solar forecasting integration. Solar forecasting already informs HEMS decisions about when to charge the storage battery from the grid and when to operate the wet goods (dishwasher and washing machine). The latest change is that the solar forecasting is now also use to choose whether to base a decision to buy electricity for water heating against a threshold related to the gas price or against the price of surplus solar PV.
The above schedule shows that, as a result of no significant solar production anticipated on the 4th, the HEMS has compared electricity price to gas price and thus elected to buy electricity from the grid to make hot water overnight since at 1.7640 to 2.4675 p/kWh electricity is cheaper than gas.
It can’t be very often that an energy company blogs about its customers’ achievements. Last week it happened. Octopus Energy wrote a blog entitled “How to hack your home for cheaper, greener, energy with our open API” which featured the achievements of its customers, and Greening Me got two honourable mentions.
For those not familiar with geek-speak, API is Application Programming Interface which is a mechanism by which an app, webpage or computer program may give commands to, or receive data from, another program – often a web server. Such APIs are often closed (that is that they are only available for use by the creator’s own app or webpage etc), but in this case the Octopus APIs are open so that they can be used by others (including me) to create our own apps, webpages, or other integrations to get data from Octopus. That data may be future price information for a UK electricity region or the actual consumption from a specified electricity meter for example. Octopus document their APIs and encourage others to find innovative uses for them.
Other APIs that I use were either documented privately by the manufacturers of the equipment concerned, although the manufacturer has not put the API in the public domain, or were reverse-engineered by myself or others by looking at how the manufacturer used it or at the internet traffic that it generated and working out how we could use it ourselves for a slightly different purpose. Such purposes would include controlling equipment other than by the manufacturer’s own app, or collecting data into some non-supported form.
Greening Me’s first mention in the blog came under the Smart Electric Vehicle (EV) Charging section where Octopus wrote..
One of our own smart energy pioneers, Greening Me, has used a Raspberry Pi and an add-on circuit board with our API to switch his electric car charger on/off and set the best time for his hot water immersion heater to run. He also has solar generation and so he can direct his solar power to either his smart car charger or hot water.
Later in the “I’ll do it myself (tech level 🌶🌶🌶)” section after describing a group of “smart home pioneers” Octopus wrote..
Together with Western Power Distribution, Passiv Systems have also created something similar to Greening Me’s HEMS, which is currently being trialled and evaluated as another BEIS funded research project called MADE.
So it’s official – I’m a “smart energy pioneer” and a “smart home pioneer”. I also quite like the idea of being a “home hacker” in the positive sense of someone who makes their own home conform to their wishes. If you’d like to read the full blog post from Octopus Energy then you can do so here https://octopus.energy/blog/agile-smart-home-diy/.
For some time now my Home Energy Management System (HEMS) has been managing many of my domestic electricity consumers including:
home storage battery
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:
self-consumption when they are enabled to use the ‘free’ electricity from my own solar panels (subject to device prioritisation) with some proportional control
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
Make and model
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
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)
Major device modes available to HEMS
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.
For some time now I’ve been thinking about creating a real time display which pulls together data from a variety of sources around the home to provide an overview of what’s going on without the need to visit multiple web pages or apps. Until the last 10 days or so that involved little more than thoughts of how I might evolve the existing immersun web page with more content (I don’t have the skills to write my own app), but then about 10 days ago I saw an online gauge that someone else had created to show energy price and inspiration struck. Ten days later I have my monitor working, albeit not complete:
The monitor pulls together information from:
My electricity tariff for p/kWh
My immersun for power data (to/from: grid, solar, water, house)
My storage battery for power in/out and state of charge
My HEMS for electricity cost thresholds between different battery modes.
The gauge consists of two parts: (i) an upper electricity cost part and (ii) a lower power part.
The upper electricity cost part is effectively a big price gauge from 0 p/kWh to 25 p/kWh with a needle that moves each half hour as the price changes. It has various features:
The outer semi-circular ring (blue here) shows today’s relationship between battery mode and electricity price. Today is very sunny, so no electricity was bought from the grid to charge the battery, and this part is all blue for normal battery operation. If the days was duller and electricity was to be bought to charge the battery, then two further sectors would appear:
a dark green sector from zero upwards showing the grid prices at which the battery would be force charged from the grid, and
a light green sector showing when the battery is not permitted to discharge but may continue to charge from solar.
In inner semi-circular ring (green / yellow / red here) currently just colour-codes increasing electricity price, but will be used to show today’s prices at which car charging and water heating are triggered from the grid.
The current price per kWh is taken from Octopus’s price API, while the current cost per hour is derived both from this and the grid power from the immersun.
The needle grows from a simple dot indicating the price per kWh only when no power is drawn from the grid to a full needle when the electricity cost is 10 pence per hour or more.
The lower power part is effectively a power meter ranging from 5,000 Watts of export to the left to 5,000 Watts of import to the right. It updates every few seconds. It has various features:
The outer semi-circular ring (orange /maroon / green here) shows how power is being consumed:
orange – shows consumption by the house less specified loads
maroon – shows battery charging
blue (not shown) – shows water heating
green – shows export to the grid
The inner semi-circular ring (yellow here) shows the source of power. The sum of the sources should equal the sum of the consumers. The sources are:
maroon (not shown) – shows battery discharge
yellow – shows solar power
red (not shown) – shows grid power
The power value shows the net import or export from / to the grid, while SoC refers to the state of charge of the battery (0-100%). The combination of import power and electricity price gives the cost per hour in the top gauge.
The needle position shows net import (to the right) or next export (to the left). The needle should thus be to the left of the green sector, or to the right of the (unseen) red sector. Needle length show the full power being handled and is thus proportionate to the angle of the sector including all the colours in the lower gauge and extends from 0 to 5 kW.
The gauge scales to fill the smallest of screen height or width and translates to be centrally positioned regardless of screen size. My intention is to display it on an old mobile phone as an energy monitor, but I can also access it on any web browser on any device within the home.
Much of the optimisation of my home exploits the cost-saving potential of the Octopus Agile electricity tariff. This tariff is a radical departure from a typical UK tariff. Rather than a fixed unit price that applies 24/7, the Agile tariff exploits the smart meter to provide up to 48 different half-hourly prices per day which change day-to-day according to a formula linked to daily electricity auctions in an absolutely transparent manner.
The prices can vary from several pence per kWh negative (i.e. being paid to use electricity) to a cap at 35 p/kWh which might apply in the early evening. That therefore places a some risk on the consumer, but equally can provide significant benefit. There are regional differences in the equation reflecting variation in the costs to distribute electricity in different parts of the country, so your formula might not be exactly the same as mine, but will be very similar.
That average 5.02 p/kWh is not just competitive versus other tariffs – it tramples all over them. Personally I’m continually plagued by advertising claiming to save me £100s versus existing tariffs, but none ever comes remotely close to this rate. Thus, with my consumption pattern, I think that this is an unrivalled tariff. The Energy Saving Trust has calculated the average UK electricity cost at 15.75 p/kWh as at March 2019 (their latest analysis at the time of writing), so I’m currently paying a third of that average rate.
Of course you won’t ever see this tariff recommended on a switching website. Indeed, I’ve never seen any smart tariff recommended on a switching website, because they only ever seem to offer the choice between flat rate tariffs and Economy 7. In my opinion the lack of smart tariffs always denies consumers access to what may genuinely be the cheapest tariff for them by short term switches between tariffs that are pretty much alike. Those switching sites don’t want consumers to find long-term value, instead they want consumers to keep switching so that they keep earning commission.
However for me, not only have Octopus demonstrated long-term value, but they provide 100% renewable power, and are the only electricity company to be Which? recommended for 3 consecutive years. For you there’s a further £50 to be saved if you click on the image below and sign-up for any one of Octopus’ tariffs.
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:
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.
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.