@BartChampagne txs - understood. I will watch it another day or two, just being curious, then go towards 0.03 next.
The brand is Pylontech, the cheap cost are a result of our City subsidizing private PV Storage, i.e. they paid for part of the storage.
1 Like
I have been experimenting with battery costs for some time. My actual costs in the DIY area are somewhere between 2-3 cents. It has become clear that at least my system runs most reasonably with the 2 cents
I have set efficiency to a low value 73%, which seems to be a realistic value for my system according VRM production report. With this setting I could set battery costs to 0 cent/kWh. DESS plans to charge the battery if the purchase price at the time of charging is only <= 73 % of the purchase price at the time of discharging. Exactly how I want it.
Hi,
sorry for the late reply, was quite busy these days.
that indeed looks very strange. As @BartChampagne already said, the current version of the hack doesn’t even contain the required “commands” to discharge to grid.
The only possibility that this could happen would be a negative Grid-Setpoint, so the system ofc. follows the request to achieve that set point. And that energy then will be pulled from the battery, if it can’t come from somewhere else.
Or, it could therefore maybe be caused by issues with the meter, that reported a grid point of -10, while in reality the system was feeding in at a way higher rate.
If you could give me your portal id (the number in the address of your vrm portal) I could look at your system and see if I can figure out what may have caused this.
Prices have dropped and keep doing so. Beginning of the year I bought my Pylontech US3000C for ~ 220€ per kWh, on blackfriday the shop send me a newsletter, containing the US5000 for 920€ (so, that’s 191€ / kWh)
I love the sound of this NodeRed script you have developed @grua ! Is it cheeky to ask if you might be able to share it? I understand it’s not always simple to do, depending on how integrated with other things it might be. If not, your spec sounds easy enough to follow, but I’m being lazy 
Thanks!
That’s a really good price ! Care to disclose the shop ? 
In my setup I currently have 2x BYD B-Box Premium LVL 15.36 kWh (30kWh total, purchased them a year apart) and their price/kWh is still a lot higher than Pylontech 
I looked at Pylontech as well before buying them but can’t remember why I went with BYD.
Probably they had a very good price/kWh back then and because I’d need a big stack of US2000’s or US3000’s to get up to 30kWh. Now it’s just 2 batteries of 2 elements each.
And I think that Pylontech states/stated somewhere that you should avoid combining batteries from purchases too far apart.
In any case, BYD’s price has dropped far less than Pylontech’s 
You mean the script for calculating the min. SOC or the script for setting efficiency to 73%? Probably the former?
@dognose I checked the gridpoint setting. It was 10W. Set it to Zero, still feeding back a few kwhrs/ day. Would be happy if you could have a look at it. If you drop me an e-mail victron-ess@lake-tech.de I’ll send you the credentials.
Yeah, the min SoC setting with running average you mentioned - it sounds like it might fix my “range anxiety”! Thanks 
flows.txt (15,8 KB)
Just renamed it from flows.json to flows.txt, because upload of *.json isn’t possible.
1 Like
@dognose I’m observing a strange behaviour.
Charged the batteries to 100% over night, now the system is trying to discharge to 80%.
I remember the old versions where the “Target SOC for AdHoc Charge” was used to define a certain level, and I think i set it to 80%.
Turning off DESS doesn’t fix the “problem”. Is there something rememberd since the new definition of “Target SOC for AdHoc Charge”?
Looks like correct behavior.
The 80% you’re seeing is the anticipated SOC at the end of the day, given the estimated load, current SOC and load profile calculated by DESS.
What were you expecting ?
Sorry, forget it, it was an error caused by the BSC firmware.
Hi @grua! I’ve been running the minSOC adjusting flow, it’s nice and neat and is adjusting my max SOC appropriately. Interesting is that the multiplus would still go to idle when I reach the new higher minSOC. So although I actually have more energy stored in the battery, I’m not able to use it all automatically.
I was just wondering if you’d given any thought to reducing the minSOC automatically so the system doesn’t revert to grid consumption when we hit, eg 30% SOC?
Sorry for hijacking the thread a bit, but it is kind of related I think!
Cheers!
My algorithm is used exclusively to slowly transfer the min. SOC from summer mode (min SOC 10%) to winter mode (35%) and back again. This is done a maximum of once a day (at night) in increments of +/-5%.
I have no other plans for this, but you are free to adjust the flow as you wish.
1 Like
That’s ok, thanks very much for sharing it.
Cheers.
1 Like
I’m not sure how quickly the DESS algorithm picks up on the minSOC changes, but I’m testing out some modifications that seem to work quite well initially. But proof is in the testing!
I pull my energy supplier’s prices and get some of the contiguous low price periods, and use that schedule to either use the summer/winter minSOC setting; or outside of those periods I set it to 10%. This does seem to bump up the max charge to around the 80%, but then also gives me more useable energy during the high-price periods.
1 Like
It does that fairly quick. Easiest to validate is to look at the target soc of the last hour. When next days prices are not yet known, DESS is targeting for “minimum soc” at the end of day.
Raising the minimum soc raises that windows target soc within a few seconds.