A couple of years ago @sysriqo adapted the MySolarPVdivert app for use with batteries. The pull request was never merged as there was an unfinished discussion on whether to split the app out into its own separate app. Picking up from that point, sparked by recent discussions on this topic, thanks to @miker@haffle@Zarch , I have adapted @sysriqo’s pull request to use the most recent version of the mysolarpvdivert app and made a few other changes. Thanks @miker for helping with testing!
The “MySolarPVBattery” app is now available via emonPi update and on emoncms.org.
It works in much the same way as the My Solar PV Divert app but has the additional arrow to show the battery discharge energy into the house and the calculations elsewhere are quite different as well.
The app requires the following feeds:
use: Household consumption not including battery charging in Watts
solar: Solar PV generation in Watts.
battery_charge: Battery charge power in Watts.
battery_discharge: Battery discharge power in Watts.
battery_soc: Battery state of charge in %.
The history view requires a number of kWh feeds. The app works with the history mode disabled if these feeds are not present.
use_kwh: Cumulative household consumption not including battery charging in kWh
solar_kwh: Cumulative Solar PV generation in kWh.
battery_charge_kwh: Cumulative battery charge energy in kWh
battery_discharge_kwh: Cumulative battery discharge energy in kWh.
import_kwh: Cumulative grid import in kWh.
solar_direct_kwh: Cumulative Solar PV generation used directly in kWh (see below).
How to test
If you have an emonBase or emonPi with our emonSD image just run emonPi update to bring in the latest changes from the Admin page.
If you have an emoncms.org account the app is now available there as well.
I don’t have a battery system myself nor do I have solar at the moment, though I would like to, and that had been holding me up from progressing this app. I have however done a bit of solar battery simulation over the years e.g GitHub - TrystanLea/solarmodel: Home Solar PV self consumption model. So in order to test and develop the My Solar PV Battery app I simulated the battery using my own household consumption and Solar data from @glyn.hudson’s system.
Being able to simulate the effect of adding a battery on your own household consumption pattern is probably a useful thing in and of itself, a bit like the Octopus Agile app it can show what the impact would be of making a particular change.
To make this process easier for others to replicate I’ve implemented a battery simulator as a process in the emoncms post-process module and this is also now available via emonPi update.
Using the post process module to simulate a battery
Navigate to Setup > Post Process
Select the “batterysimulator” process
Select your solar pv power feed
Select your house consumption power feed
Review the suggested parameters such as battery size and max charge/discharge rate
Review the suggested output feed names, these are feeds that the process will create that the app will then load to provide a visualisation of the output.
It’s quite fun seeing what the result of adding the battery and solar in my case would be. Over the last month, a small ~1kW ish solar PV system and 4.4 kWh battery would have supplied 58% of our power consumption which includes a heat pump and EV (both used less over that period due to warm weather and lockdown). The battery would have increased self consumption of the solar power from 39% to 97%.
Before I spent £££££ on a battery, over a year I was using 50% of my pv generation, diverting 25% to my HW tank via a Solar iBoost and exporting the remaining 25%.
Since getting the battery the Solar iBoost captures almost no excess generation, but according to my battery app so far in May I have exported only 4%, only 7% in April, & only 6% in March. So similar figures to yours.
Yes that’s correct, not including consumption of power charging the battery.
The app doesn’t really work with grid charging of the battery yet, that’s still a key missing piece unfortunately. The import_kwh is for consumption not covered by the battery or solar directly but assumes no charging of the battery either…
I need to think through adding in grid charging of the battery!
Great work on this one - looking to set up the simulator ASAP!
@TrystanLea - assume I need to build new inputs for emonPi to then get feeds? I am currently running emonPi PV (tye 2 setup). I don’t suppose you can provide a quick guide on this part so that I have battery_charge, battery_discharge, battery_charge_kwh, etc.for app inputs without breaking all my things?
@haffle a battery app without off-peak charging support is not really a battery app so I’ve managed to add this in (available via standard update process)…
To get the history view to work the app needs a feed of cumulative kWh of solar used directly by the household (not via the battery).
We can calculate solar used directly with the following:
solar_direct = solar
if (solar_direct>consumption) solar_direct = consumption
I’ve had to add a new input process to make it possible to calculate this. The input process limits an input value by the input value of another input.
The following input processing example shows the solar input configuration required:
1 and 2 are just recording the solar feed and calculating cumulative kWh of solar generation.
3 is applying the max limit process, here we are limiting the solar value by the consumption value (assumed on CT1 in this example).
4 and 5 are logging the result to a solar_direct feed and a cumulative kWh feed.
The simulator will build all the other feeds for you, it will also build a new import feed so you want to make sure that you give that a different name to your current import feed.
Note that depending on how much data your use and solar feeds current use the new feeds will consume 8x one of these feeds. So I had a 13MB solar feed and so all the new feeds added another 104MB or so…
I’ve updated the batterysimulator to include a basic offpeak charging option. You can specify the start time and the target SOC in % of the offpeak charge session.
Ideally it should look at what the solar PV output will be in the day ahead and reduce the offpeak charge session if its due to be a sunny day. I also wonder whether it would be best to stop the battery from discharging during offpeak hours so that the battery is reserved for the morning and evening peaks.
Looking at my graph I have quite a bit of the following happening:
Here the offpeak battery charge starts at 3am, then at 3:30am you see the car charging starting. at 4:30am ish the battery reaches the target SOC and then starts discharging straight into the car battery, which at that point in time is just going to increase battery wear for no gain in terms of grid peak reduction… (the high ‘standby’ is the heatpump ticking along at 500w all night, this was earlier in the year).
Interested to hear peoples real world experience, is there a setting on battery systems to stop this from happening?
Im not sure what guidance to give in terms of input processing setup yet given that there are a lot of different configurations of battery systems possible. If you cant quite make heads or tails of the above feel free to list the inputs and feeds that you do have for your house consumption, solar and battery system and I will try and work out what’s needed to get that working with the app…
Hi Trystan, great addition, just in time for my upcoming kickstarter-investment: Orison.
After updating I have the My Solar Battery available.
Now I see the latest Postprocessor is installed (v2.1.0) but I still don’t have ‘batterysimulator’ available there. Any idea what goes wrong on my side?
My battery configuration will be:
System 1: Orison master 2.2kWh + slave 2.2kWh
System 2: Orison master 2.2kWh
At first I will make separate feeds for both systems and make a cumulative feed for display in the app.
It would be nice though if separate (de)charging and SoC could be made visible. I will think how to display it nicely…
Do you know if its possible to get this via an API from the moxia battery itself?
I could make that feed optional in the app as Im sure it wont be something we will be able to get in all cases.
For the CT on the battery connection, you will need to split that into a separate charge and discharge power feed. If its positive when its charging and negative when discharging the following input processing should work attached to the input associated with that CT:
This is getting better and better. But I might need a little help in getting the solar direct consumption. If it helps, herewith a list showing what I record at the moment …
@haffle do you have a feed that is just household consumption, not including powerwall interaction? is that house_nett? or the feed called “Consumption”
