planning battery charging/discharging with hourly electricity prices (now incl solar)

[willemd]

I have now created a python program to optimise battery charging/discharging profit using hourly electricity prices. The program is published on github here https://github.com/WillemD61/battery-planning. Description is in the readme file on github.

It is a follow-on from my script to load hourly electricity prices from entsoe.eu (viewtopic.php?f=59&t=39423)

It is currently standalone but the plan is to integrate it into domoticz.

My plan is to do a simulation, since I don't have a battery yet.
1) read the prices from the historic variables created by the entsoe script (or just re-read from entsoe as-is).
2) find a way to display the future prices in domoticz/dashtics, also if prices are negative
3) read current battery charge from a domoticz device
4) read battery charging/discharging characteristics from domoticz user variables
5) take into account surplus solar energy (currently delivered back to the grid), read from p1 meter.
6) use dzvents to run the planning every hour

Since I don't have a battery I will not add any device switching to start charging/discharging. I will just simulate battery ownership to support decision making, but the output of the program could be put on devices and used for switching purposes.

[ubfssF]

Nice! I was planning on something like this in Python as well, but you are a few steps further. A few things I was thinking of, aside from simulating one or more virtual batteries:

• creating an email every day after 15.00 with optimal time to run the dishwasher (cheapest 3 hours during the night), best hour to start the washing machine (highest load is in the first hour) and a graph with the prices for the coming 24 hours. And also the gas price for the coming day, just to be aware of strange fluctuations

• influence of the price ceiling in the Netherlands

• saving of the prices to a csv-file, to enable myself to evaluate by hand in excel

I will share the Github url within a few days.

[willemd]

Nice! I was planning on something like this in Python as well, but you are a few steps further. A few things I was thinking of, aside from simulating one or more virtual batteries:

• creating an email every day after 15.00 with optimal time to run the dishwasher (cheapest 3 hours during the night), best hour to start the washing machine (highest load is in the first hour) and a graph with the prices for the coming 24 hours. And also the gas price for the coming day, just to be aware of strange fluctuations

• influence of the price ceiling in the Netherlands

• saving of the prices to a csv-file, to enable myself to evaluate by hand in excel

I will share the Github url within a few days.

You can simulate multiple batteries just by providing higher capacity data to the program (is user input already). This is valid unless you run into network limitations (such as max current in your home network). I did rerun the full year 2022 for two different types of batteries to check what the payback time of such an investment could be. (approx 6 years)

The program does already output a file than can be loaded into a spreadsheet. It is not a csv but if you load and indicate space as a separator (and treat multiple spaces as one) it will load well into excel. Alternatively you can modify the output function to include comma's to create a csv.

I will keep the gas price out of it since this changes only once per day and you cannot do much time-planning for gas usage. Also the price ceiling is a temporary measure and I have no plan to add it. That's all about nett usage per period while the above planning program creates a zero nett use plan (unless you start with an initial charge, which is planned as sale as a first step)

Best time to run heavy electricity consuming devices would still be low period prices, especially if they have not been 100% planned for charging (last column in output). If you run such a device at a different period or have other high usage or high solar output, just rerun the program the next hour to re-optimise. If you have surplus solar power, usage should follow the planning, i.e. charge the battery with it if charging was planned or deliver to the grid when uncharging was planned. If nothing was planned I guess it is probably best to re-plan setting a zero price for expected solar hours. This is a point I will consider further.

Have fun.

[willemd]

New version with Domoticz integration now available on Github. https://github.com/WillemD61/battery-planning

[heggink]

I am also looking at a solution like this but one with a few more options including solar panels, electric cars, electric water heater with the goal to find the most optimal mix depending on charge capacity, charge/discharge power and so on.
There are commercial solutions (bliq) but they don't really cover anything beyond just a battery and there are open source solutions like https://github.com/Netgalleria/arska-node
I have yet to find the ideal basis but I am sure that many are interested and maybe willing to contribute.

[willemd]

A simple addition I will make next is to indicate in the planning what the remaining best hours would be for heavy electricity consumers, like washing machines, tumble dryers, dish washers, electric cars etc.

Then I will continue with taking into account real-time and predicted consumption/production.
For the real-time aspect I will assume:
1) A battery system in charge mode is an electricity consumer and will first take electricity from the solar panels before drawing from the grid (like today any device will do).
2) A battery in discharge mode will deliver energy to the in-house grid for any consumer, only surplus will then be delivered back to the grid (like today the solar panels do).
For predictive aspects, I will probably try the route of using api.forecast.solar. I am already loading that on a daily basis to see whether it is reliable enough. And in the planning I can probably add that as extra hours at zero costs and create possible charging moments out of that, as alternative to drawing from the grid.

Thanks for the link. I will have a look.

[heggink]

That would be brilliant! I am traveling the next 2 weeks but will take a look where I can help.

[willemd]

A simple addition I will make next is to indicate in the planning what the remaining best hours would be for heavy electricity consumers, like washing machines, tumble dryers, dish washers, electric cars etc.

The above has now been added. The top 5 lowest prices are highlighted in the displayed planning on the text device for the hours that are still free to use (unclassified).

[heggink]

I really like where this is going! Thanks for the work!

[willemd]

The new version at https://github.com/WillemD61/battery-planning now includes the option to include solar panel production forecast into the planning (that was hard work !!). Since actual production will deviate from forecast, it is recommended to re-run the planning at regular intervals and the program has been adapted to make this possible (but maximum 10 times per hour due to maximum number of allowed calls per hour to forecast.solar api)

[jake]

Thanks for the hard work! I reviewed your documentation and I have 1 point of improvement:
Add units to your explanation of variables: I assume that battery capacity is in Wh, charge speed is in W, angle is in degrees etc. Just to be sure.

[willemd]

I extended the planning program now with a conversion efficiency percentage, meaning you can indicate what the efficiency is and the program will then calculate charging/discharging optimisation taking that percentage into account.

For example with a percentage of 90, you need to take 1.1 kWh from the grid to get 1 kWh into the battery and when you discharge 1 kWh from the battery back to the grid you will get paid for 0.9 kWh.

As result of a lower efficiency, the profit from charging/discharging will go down and also certain combinations of charge/discharge hours will no longer be viable.

More info here https://github.com/WillemD61/battery-planning

[Ray-Man]

Hi, I really like your script but there are some things I can't get working:
1) the hourly action gives the following error: Planning output not as expected, no JSON received. I can read (sort of) scripts, but I can't figure out why this JSON isn't published/readable. The TXT is updated, but because of the bad JSON, the selectorSwitch isn't updated.
2) The PV data always shows +0 in the TXT device edit: if I use the real azimuth (in my case 125) I do receive data. Could it be that south=0 is not correct?
3) if azimuth south is 0, does that mean that if real azimuth (north=0) is 45grd, the variable should be 225? Or should it be -135? Eitherway, PVdata isn't updated.
4) is it possible to change the script so it will store the data in a Global persistent variable {history=true} edit: and devide the data with "|" instead of "____"? <-figured that out....

Thanks in advance for your reply!

[willemd]

For point 1: I don't have access to my system right now so cannot test/investigate. I suggest you run the program manually with the relevant command line arguments to see what is wrong with the json.
For point 2 and 3 you can look at the instructions at the forecast.solar website.

[Ray-Man]

1) somehow it started working. I'm not quite sure why but suspect one of the reboots I did, made it start. Anyway, it works and that is enough for me.
2 & 3) that explains indeed a lot! I assumed (yeah, I know) that south=0 automatically meant north=180. That is the case but that doesn't mean east is 270. It actually is -90. https://doc.forecast.solar/find_your_azimuth

Thanks for your reply!

[Ray-Man]

OK, so for the last 2 years the script worked pretty good and it still does! Many thanks for that!

However, in October Tibber (and I assume ENTSOE as source as well) will move to a quarterly setup. Is it possible to:
1) change the script so it can update prices per quarter instead of per hour?
2) change the script so it reports the local time including DST?

Especially for the second request I noticed that the ENTSOE output compared with the Tibber current price differ with one hour. The only explanation I could think of is the Daylight Saving Time (a.k.a. 'Zomertijd'). Sould correct itself by the end of October, but for now (and every summer period) the charge/decharge control has an offset of one hour comparred to the data Tibber (and I assume other vendors) use for calculating.

[Ray-Man]

So the script stopped working because Entsoe switched to a 15min resolution. I lack the knowledge to change the script so I'm hoping somebody is able to change it?

[willemd]

I am not actively maintaining that program anymore because it has already served its purpose for me, i.e. showing that a home battery does not have sufficient payback for me and increases my energy consumption. Probably switching to 15-min prices would also be quite a change since the hour-nr is used actively in the program.

I will however have a look in the next week or so. If it is easy to fix I will do it, but I am not making any promises at the moment. Sorry.

[Ray-Man]

Hi WillemD,

Fair enough and fully understandable, still hoping of course. The second part of my energy control heavly depends on your script. I dynamically 'split' my battary capacity in a Consume and Trade part were the last one is only charged at the lowest prices or with exess solarpower. The Consume part is charged when prices are below day-average. Discharging only occurs when Trade part is above 0% and the price is high enough. Worked magic for my energybill.

Strange thing is that today your script is working again, but when calling the API directly, I still see a 15min resolution. The XMLs and TXTs also show a 15m resolution.

[willemd]

You can run the script manually from the command line and use the -t or -v parameter to switch on tracking or verbose mode so you can see what is happening.

It will probably still get a pricelist from the entsoe site and build a pricelist with 4 times as many elements as before because of the 15minute prices. At the moment, without diving into the code again, I cannot say how the optimisation then will handle this. Maybe it works, maybe it just uses the first or last price of the hour, maybe some other "confused" approach.