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

[willemd]

addition: I did a quick check myself using a manual verbose run for today.

The construction of the daily hour list is wrong. The program receives 96 prices for today and builds the price list. But then it takes the first price as the price for the first hour, the second price as the price for the second hour, third for third etc. This is of course wrong when those are 15 minute prices. It also stops after having processed 48 prices since it will optimise maximum until midnight tomorrow.

So the optimisation will run but will use the wrong prices for each hour.

Quick fix would be to convert 15 minutes prices into hour prices and then run as normal.

[willemd]

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.

I have now adapted to program so it will still function correctly although sub-optimal. The program now takes the 15-minute prices and calculates hourly averages and then performs the optimisation as before using those hourly averages.

Fully adapting to 15 minute optimisation is quite a change and would require more work, as explained. For now it will still deliver a reasonable result, especially if your energy provider also still works with hourly averages.

[Ray-Man]

So, thank you so much for your responses; I really appreciate them. The problem is that my provider actually uses 15-minute prices (Tibber).
In the meantime, I've tried (and am still trying) to reverse-engineer your script in Excel to better understand how it works. So far, I've come to the following conclusion:
- I have a serious lack of knowledge of Python.
- A complete set of prices (element1-element2 combinations) now requires "storing" over 10,000 line items.
- After the minmax/maxmin sequence, there are still about 5,000 line items required, for which I don't yet have a solution to store them with Dzvents (<- because even though I'm still at beginner's level, I know more about it than I do about Python).
- I find this too interesting to give up...

I will update the script to the one you've changed, but since I made some small adjustments in it for other purposes (I changed the creation of the list so I can use it in my other scripts) updating it at this hour will probably even do more harm. First a good night sleep......

Again, thanks for your effort!

[Ray-Man]

In the script rows
350: # print("processing price ",price," for qtr ",priceQtrNr)
356: # print("new avgprice",hourAvgPrice)
prevent a proper JSON to the dzvents script.
When commented out, the script works flawless!
Thanks!

[willemd]

Yes, if you are feeding another script then those info/debug print statements should be commented out.

I agree the program is hard to understand if I look at it now. It grew organically during development so I should really start from scratch with a proper design, taking into account 15 minute prices, hourly PV forecast, varying tax percentages and amounts, purchasing costs on dynamic contracts, end of Dutch "saldering" coming up, battery efficiency, battery cycle costs considering max cycles guaranteed. (and maybe more ?).