Emoncms Solar Battery Simulator app

To complicate matters on the export payment front.

Some of us with older Solar systems (pre March 2019) are on the deemed 50% FIT export terms.
So no matter what we export (a little or a lot) we get paid 6p per unit for half of what we generate.

This is RPI linked each year and is guaranteed for 25 years from install.

Yes, you can opt to move your export terms to the likes of Octopus Agile. Leaving FIT generation payments in place and untouched.

1 Like

Thanks @TrystanLea for providing this, I have run this after changing the Tariff details (Octopus Go 2030-00:30) and it appears that there’s no provision included to top up the battery from the grid during off-peak hours during days of low solar generation which would offset the higher tariff cost during the following day.
Could you look into including this because my payback is around 10yrs using the simulator app and if it included off-peak battery charging it should be significantly lower and easier to guesstimate battery capacity.

Sorry, I have just re-run the sim & it does actually top up the battery during off peak times :blush:

1 Like

I don’t understand what the winter/summer start SOC% are doing; can someone explain please?

In the summer you might want to avoid too much overnight offpeak charging as the battery will then be more full during the daytime and may not be able to utilise the available solar energy. In my example settings the battery only starts charging in the summer if the battery is below 60% soc and finishes charging quite early at 75%, providing some room for solar the next day. In the winter you probably want to charge up the battery even if it’s already at a relatively high state of charge and then charge it up as high as you can, hence the example setting to start charging if below 70% and charge up to 100%.

Ideally this would be controlled by a day ahead forecast of available generation which would let the solar do most of the charging if it’s due to be sunny or alternatively when cloudy do more offpeak charging.
It wouldnt be too hard to implement this in the simulator and I may try to add that at some point.

1 Like

That’s great, thanks.

Maybe a very stupid question, but how do you enter the tariff & costs (is the “rate” the price per kWh?) and what is the off-peak start / end?

PS i’m running this app without updating everything by just commenting out the lines

//feed.public_userid = public_userid;
//feed.public_username = public_username;

@TrystanLea Having a go at this now, but as we don’t currently have Solar installed, I’m looking at simulating representative data for our location and proposed install attitude.

This gives me some data to start with, but the best I can get from there is hourly power figures. I’ve massaged its CSV export in Excel to include UNIX timestamp, cumulative kWh, and am attempting to get it working with the simulator.

Are there any particular requirements on the feed type and intervals? Initially I imported it as a fixed interval feed with hourly increment, but the app appeared to place the solar generation at the wrong time (possibly condensed around the midnight mark - I forget?).

I’ve since tried importing with a 10s interval feed (populated with the 1h data), and have tried post-processing using “average” to try to padd the 1h data to an averaged 10s feed. Not completely sure what is required to get it working nicely.

Peter

1 Like

I’ve been experimenting with the app and have found it thought provoking and interesting and very useful.

From using in tonight, some things occurred to me and I thought it might be worth expressing them as it might not be clear to other people, as it was unclear initially to me.

  1. The black line for SOC. It took me a long time to realise that it related to the 0-100+ scale, and not reading on the KWH scale. Given that the battery has a known capacity, is there any particular reason that 100% doesn’t tally up with the stated capacity of the battery?
    (Reusing your graphic)


    So using my theory 100% would appear just above 8000, and not at 10000 as it currently does.

  2. Units. To me it was confusing to be using Solar capacity, charge rate, discharge rate in Watts, but Battery capacity in KWh. It might be nicer to put them all in W & Wh; all in KW & KWh; or include units in brackets as you have done with (£) and (Years)

  3. I didn’t initially understand the rationale behind the default SOC figures, until I re-read all this thread. Perhaps it would help to add something like your explanation text from this thread to the app-setup page?

In my example settings the battery only starts charging in the summer if the battery is below 60% soc and finishes charging quite early at 75%, providing some room for solar the next day. In the winter you probably want to charge up the battery even if it’s already at a relatively high state of charge and then charge it up as high as you can, hence the example setting to start charging if below 70% and charge up to 100%.

I hope this post is useful. I have found that my writing style often appears critical even though I try very hard for it not to seem so.

Steve

1 Like

Might be worth trying half hourly or 15 minute resolution and the Log to Feed (join) input process which would fill in the gaps…

Thanks @steve-oemon that’s useful feedback, cheers

Not really, perhaps it would be better to display in kWh…?

It seems best to me.

Perhaps the only downside would be if the battery was small and the daily usage was high, the so it would be a small wavy black line at the bottom of the graph.

1 Like

@TrystanLea Thanks…

I’ve not really figured out how to do that, as my raw data is an hourly CSV. I’ve been importing this into a feed, am not really clear on how to loop that via “Log to Feed” to fill the gaps. I’ve jumped straight to getting data in a feed, with updates every hour only).

FWIW, I patched the app on my instance to allow “Hour” resolution (3600s interval), and when I select this my original feed works ok with the app. My consumption data is finer grained than this (10s), so even with smoothing the solar feed it should be more accurate to process at a finer resolution - but I expect the effect will be minimal.

Your numbers are coming in very close to the predictions on our quote, which is reassuring. (We gave them only approximate yearly consumption figures). I guess this helps to validate the method of pulling arbitrary data from the GIS database to simulate a particular potential solar install site.