Strange plan for battery charging

[khostri]

Contact Details

jan.slaby@outlook.com

VRM / Site iD

210204

Country / region

Czech Republic (cz)

B max

20

TB max

8.5

FB max

8.5

TG max

9.9

FG max

12

Battery costs

0.04

Buy price

(p+0.150675)*1.21

Sell price

(p-0.0276)*1.21

feed-in possible

yes

feed-in possible

yes

What happened?

Cheep sell price, PV Yield expected, but battery charging only at one hour and only to half capacity to be discharged completly in the evening. This setting is fro 0.04 battery price. It would seem partially correct to charge at highest price, but comparing selling price during the day, it doe not make sense not to charge battery to full, or to at least 85% or so.

If I change battery price from 0.04 to 0.05, no charging at all.

Battery is already at 35% SOC as result from previous day running algo. Yesterday there was real PV yield 25% of expected (heavy rain), but algo still didn't do any recaluclation.

Today I have even switched from Optimized for BatteryLife to Optimized without battery life as previous mode doe not work with algo and on contrary leads to cycling battery at minimu active SOC

Changing to battery cost 0.03 leads to battery charging:

but dischargin is always the same - so even in case that selling is somehow calculated as more profitable than charging, ie charging is expensive, it does not make sense to discharge batery to min SOC in that case. Or not charging to higher SOC before discharging.

Relevant log output

No response

Screenshots

[khostri]

Trying to play with very low values like 0.001. I can understand that algo compares battery charging price to "lost opportunity" for not selling to grid. So maybe that is the reason batery is not charging to higher SOC. But I think it would be nice to work with some unknow or statistically expected facts. From my point of view: Battery price is calculated from cycles. In reality there is like 1 cycle per day max expected, in average less. So in fact if battery has 3000 cycles or 10000 cycles is in reality same outcome regarding batery usage, wearing out etc. Also prices are published only one day ahead. So calculation cannot plan for following day like conserve energy for higher prices. But it can be expected that there will be lower PV Yield probably, additional consumption etc. So planning only for day in the end lead to buying more expensive energy from grid when battery is on minimum SOC. I would think that having battery charging slightly prioritized would help a lot. So use 2 prices in config (chargin and discharging) or from one curent price for charging discharging use it differently (with coeficient) for charging. I dont know what coeficient would be ideal, but during low selling prices doing battery charge even if hard calculation says selling is still slightly more profitable would make sense as following days/cloudy hours would be more profitable for sure.

[PoolsideKelbi]

Hey @khostri, thank you for your post.

From reading your comments, I have identified a several points of confusion/questions that I would like to clarify:

1. The algorithm does consider tomorrow's prices, consumption and PV yield estimates (from the moment tomorrow's prices are published). This is not expressed visually on the graphs because Node-RED implementation is only a proof-of-concept :). But the documentation perhaps should reflect this fact to make it clear.
2. It seems you have understood the reason behind why the discharge is always happening: because it is still profitable to do so since it is energy that is present in the battery. It is important to note that the algorithm only works with the future, so what happens in the past (the price at which it charged) is irrelevant because the algorithm only sees it as the available energy in the battery at a given moment.
3. The partial charge that happens at 13 when the b_cost is below 0.04 is because it only considers the PV-yield as the profitable energy at that time. Looking at the buy/sell prices of the installation, it is hardly ever profitable to do energy trading using the grid since buy price is greatly higher than the sell price. But PV yield is 'free' in that way. And the reason why the charge/discharge (at 13 and evening) does not happen with prices above 0.05 is because the battery costs of that operation outweighs the earnings you would get from selling it to the grid.

I hope this provides a bit more context as to why the algorithm works in the way it does.

[khostri]

Hey @PoolsideKelbi thanks for explanation: difference in buy/sell prices is due to high fix fees on distribution here

1. ok, understandable and I logical from the point prices are know that algo calculates with that

2. from the perspective of simplicity to implement I can uderstand. But I can imagine to do correction as I have posted in other issues/comments

   • Pv plan coresponds with reality, correction factor for Pv Yield <----|---->
   • Pv plan is higher than expectation in past timeframe <-------|->
   • PV plan is lower than reality <--|------> so you would know that plan to charge battery in 1 hours would probably be incorrect and will be expected/lower/faster. For calculation purposes you would use corrected PV Yield value

3. understandable, but I am not happy with that in my hearth - that why I have tried to find approach with 2 prices as selling on price 0.04 is profitable, but not charging with the same price. Using separate price for battery charge and battery discharge would help it for different needs.

Also as pointed in my other bug report, negative price (when it would make sense to trade with gfrid) does not work well with my settings, so even if price is under zero, algo was not able to work it out correctly for charge/discharge (still selling at negative price)

[khostri]

Sorry edited comment regarded battery price - I was doing several simulations and maybe for consideration on your side - instead of battery price it would be better to provide total battery cost, expected lifetime and weight factor of battery charging vs battery dicharging. Because then you can calculate not only battery cost, but for defined timeframe expected number of cycles per day and adjust algo based on that including priority for battery charge if needed

[khostri]

Hey @PoolsideKelbi posting another screen - as today there are more extreme values its more obvious. Even after your explanation I still think there is some issue with algo. Now the selling price is negative. Buying price is 0.21 / kWh. Battery cost is 0.04. One hour ago algo was still feeding into grid even with negative price. Now it switched feed in to false. But buying energy from grid, not charging battery (and no charging in the daily plan) and also not using battery even if battery price is 5 times cheaper than grid. Also it means system will in the end of the day has nothing in battery and next day will be more costly in any case. Yesterday battery was discharged to grid so I have thought system will charge it during sunshine.

Grid point still at -9.9 which is wrong in my oppinion and scheduled charging active with target of 15%. Which is also wrong I think. going to turn off algo for now

this picture is also during negative price...

yesterday discharging

[khostri]

Now at 12:20 battery reached 100%. So I tried to activate algo. There are still negative prices, but current state is like this:

It seem s as I already commented in other issue, that Grid setopint has priority. Not only over Iddle state, but over Feed in state as well. So because Setpoint is at -9900, it still feeds in even in time it should not.

[banne123]

I had the very same problem in another (unsolved)topic, I disabled the algo for now. There is a major bug somewhere

[khostri]

just for confirmation - tried to activate algo now at 20:20. Price is positive, but very low like 0.05 for selling. Right after activation system started to discharge battery into grid with full speed, ie 9900 as set up on grid setpoint. So disable it 30 sec after activation. I was forced to prepare even dashboard with simple slider to be able to setup gridpoint to 0 after deactivation otherwise it takes like 1 minute to use Remote console to put it into working state again. Setting Grid setpoint only really makes difference For the test I have also tried to increase battery price to 0.07, whic is higher than selling price. behavior is the same:

I have my thoughts about that:

1. Grid setpoint is probably compared not against price after formula, but agains price before formula, ie only downloaded dynamic price. But Grid feed in is based on values after formula
2. Feed in and setpoint need to be setup in combination - grid setpoint needs to have more values than min, zero, max.
3. In different scenarios, combination of values has to be different. Ie for not discharging battery, setting up only grid feed in is not enough, setpoint needs to be 0. Or value around zero, like -100 for feed in, +100 for not feeding in
4. battery charge price and discharge price has to be different for calculation to be able to preserve battery
5. in case of high PV Yield, no feed in enabled because of low price, algo should take PV income as free ie using it for battery and not setting up battery to idle.

[khostri]

Tried to turn in on again in the morning, but still system feeds in even in negative price. Now tried again - at 11:05. According to graph it seems as expected scenario. Also no discharging battery to grid, but system still feeds in. In fact oscilating from and to grid. changed batetry price to 0.04. At 0.07 no chargin was planned at all even in this case 0.07 battery price would be still better than buying form grid, or even selling at negative price.

[khostri]

turning on algo in 13:30. Current state seem almost ok. Only thing I would do differently is that its buying from grid even if there is excess PV Yield. Current production is limited because its pushed only to battery right now and battery is limiting that. Otherwise production would cover both charging and AC loads - tried to set it manually to check that.

Grid Setpoint to 0:

After algo set it back to 12

[khostri]

Hi @PoolsideKelbi playing with algo still :) Had it turned off for the yesterday evening and this morning until battery reached 98%. Then activated algo. First action was algo started to deplete battery into grid at full speed alloved even it should not to. also no scheduled charging was planned to put battery to idle (checked in console). With my slider I have just changed Grid setpoint to 0. It started to charge battery as without algo with excess going to grid. But interesting thing is that in next tick, algo changed setpoint to -9900, but was able to schedule charging. Now its expected scenario to have battery in idle with excess to grid. Maybe there is different command sequence needed while changing values? Also I wonder how it will work on 16-17 where it should charge batery to 100%. (as mentioned before and in other issue posts charging does not work mostly in expected times) Also I dont understand, why discharge on 19-21 will leave battery discharged at value, reaching 15% (minimum SOC) on midnight. Shouldn't it be that minimum soc according to plan should be reached just before next day sunrise? Adding screens from current state. Also actual battery cost is set to 0.04 although real value for my battery should be 0.07. In that case no charging at 16-17, but discharging still planned on 19-21

[khostri]

Discharge was processed as planned although not fully (probably system was unable to do it in just 2 hours). But today no charging again - system planned to discharge battery to minimum. Also buys for high prices in the evening as consumption is covered by grid. Today system plans to sell all excess into grid instead of charging. I know that battery price is lower than sell price in average, but doing calculation: Manually I have forced to charge system by 66 % soc = 13kWh. Difference between battery price for charging and selling 13 kWh to grid si exactly 0.71 EUR for whole charge cycle. (average price for selling 13kWh was 1.2298, average price for battery charging was 0.52 EUR But buying from grid yesterday was 0.23 EUR more expensive, today morning it was 0.09 EUR more expensive than from batery. It means. 0,32 EUR more expensive. So final difference is 0.39 EUR for not letting battery charge by 13kWh, leaving it in discharged state for next days. As have pointed earlier, i think the difference is so small, risk for paying more because no battery reserve is higher and higher not mentioning blackout, that battery charging should have priority with specific setting or at least that priority be selectable.

[dirkjanfaber]

If you want to be safe for a blackout, the solution is to increase the minSOC. It is important to note that the algorithm only works with the future, so what happens in the past (the price at which it charged) is irrelevant because the algorithm only sees it as the available energy in the battery at a given moment.

[khostri]

Hi @dirkjanfaber Yes, but as I have pointed out in another issue, algo does not work with Life optimized mode - it still stries to go to min soc, not actual soc. Also I understand that its based only on future. But even in that case I have pointed out, that prices are not available more that one day ahead, common sense says that if you dont have risk buffer, it will be always worse - it just depends when. (risk buffer = energe in battery) Thats why I wanted to give feedback, that current algo battery prices should be probably used differently in calculation with connection to charging from Sun. Also, that mode change does not work in 100% percent maybe because of specific sequence.

[dirkjanfaber]

At the moment our efforts focus on adding native controls to the Venus OS (instead of creatively using the currently available controls) and also modify the algorithm to work with these new controls. This is going to address most of the current issues. Do expect it to take some more weeks before we will be able to release that.

[khostri]

Ok thanks. :) I am looking forward towards that release. So I will probably turn off flow for now. Mainly because that feeding during negative prices and not charging when expected.

[DarkFiguringitout]

I am also confused with the algorithm at times. When switching from night to morning, the battery will go into idle for no good reason, even when electricity prices are high. Then the same issue occurs in the evenings when the sun sets, and the solar power is slowly getting close to not being enough to power the house, it switches the battery to idle. That is a very undesirable effect, and I have to switch to manual or different methods to control the power. I can't see why the algo would set the battery to idle at 70% charge.

[dirkjanfaber]

We've released an updated version, which now sets a target SOC for the battery to follow.

As this uses a different approach, you will need to:

• update Venus OS (to 3.10 or above)
• update the victron-dynamic-ess node to version 0.1.2
• update the example flow
• reconfigure the Dynamic ESS node (using VRM portal ID instead of Site ID)

More information can be found in the release notes and README.md