I recently switched over to a dynamic contract and activated DESS.
I have a issue that my victron system is not able to maintain the setpoint (-100W in screencapture below). During normal ESS (before I activated it) I set it to -20W to break-even on my meter. But even with -100W set, it still just ingores it. At night it is able to maintain the correct setpoint (put it back to -20W at night). So it looks to me it has something related to solar production.
It is also visible in my overal usage measured at my metering port (P1). At night → flatline. Daytime → hard to maintain. I have already 1 year of experience with regular ESS, and never had this issue.
Does someone have pointers for me to fix this issue?
Depends on the multi, I had issues with balancing on my multi ll 5000, in the end I got it changed for a 10kVa so I could shift all loads to critical load side and just get the multi to read the load through itself, PS it might be better to shift the PV to the output side of the multi rather than coming through the multi from the input side
DESS takes no active input on the setpoint. If it is charging or discharging, there ofc won’t be a setpoint to obey, and for the times where it is, ESS has to take care.
What Gridmeter are you using? Which Multiphasemode? (Total or individual?)
What are your Phase values like, when this happens?
From your video I conclude you have a single inverter on a 3 phase grid?
I was afraid the DESS doesn’t respect the grid setpoint and this kind of behaviour is by design.
I use the Victron vm-3p75ct with Multiphase regulation = “Total of all phases”.
Powerfactor values are quite low when there is not that much consumption (0,1 values or even lower). But that is not different when using ESS mode which does respect the setpoint.
I indeed do have a single inverter (Multiplus II 5000/48) on a 3 phase grid and an AC inverter on AC-in (main board). I don’t have any AC-out connections. Except if that’ll solve some issues as Daza suggests?
To be honest AC solar fluctuate a lot, and you seem to have a constant heavy load on the multi, I found the Quattro to work better than the multi don’t ask me why it just did, my dealer couldn’t work out why either but I needed island mode so that was a no go, I was splitting loads over ac out and ac in getting the multi to cover both it wasn’t great, having to go to -200watts to cover the dips with cloud cover, this is why I told them sticking it all on AC out would be better and got the unit changed for the 10kVa but I use the multi’s own inbuilt current monitoring rather than an external monitor, is it possible to charger your batteries on off peak power and then reduce the charge going to the batteries in the day I think this could help without you changing the wiring. Give it a go via NodeRed I have it in my GitHub I’ll grab the link in a sec. PS this will reduce the batteries charging ability to about 200watts see if that helps you this is only used in the summer months but adapt it to suit if you wish
My only main goal with my installation is: as much self-consumption as possible. I have to much solar energy at the summer months, which I have to push on the net for 2 to 3c€/kWh. The reason I switched to dynamic tariff and DESS is to sell my surplus solar energy when price is high. All other moments should be 0-on-meter. That’s the reason I’d like to have DESS taking care of “when and how much” energy to sell and a grid setpoint of -20W to make sure I don’t draw unnecessary energy from the grid.
As far as I understand with my 1 year experience: my hardware doesn’t have any difficulties holding this -20W setpoint. Only DESS is not taking this setpoint into account if it is charging my surplus solar.
In that case the GitHub thing won’t work for you if you’re using DESS, so what’s the thing drawing the constant load? Heat pump? Yes I would try pushing rather than pulling and I’m still of the assumption that the multi is a better current reader than the CT’s as I used the one the multi came with then the ET-112 and then the VM-3P75CT and the multi seemed to perform better but as you seem to have the multi just on input covering loads you can’t do away with the current monitors. But I would try to move AC PV over to the out put and fire back, does it do it more in the winter? As I found this would be the effect on my old 5kVa
The load is airco (heat pump), yes.
But the behaviour is the same without any load (+/- 200W idle consumption).
I recently switched to Dynamic tariffs, because of my excess solar. Not tested in winter yet. But for the rest of the 1 year this system is running … all was good (-20W flat).
Try reporting it as a bug to the software team, and see if they can replicate it but you may find your device might be what they need to have a look ie remotely accessed, but this is just an assumption
This is another screen capture of today while charging. In this case it looks like grid import is matched with my consumption. There is in my opinion no reason to import any electricity because the import price is never lower then the (known) sell price. If it was the case it could sell the electricity I’m producing for more then I"m currenty importing, I’d agree with that decisions… but it is clearly not.
One Issue contributing to this is your “symmetric low” consumption:
Grid-Meters have a minimum current they can measure. That is typically round 0.25 or 0.5A. If the current (per phase!) is bellow that, the meter is “guessing” a bit.
So, while you have 10ish watts on L2, L3 (“guessed values”) your MP is trying to balance on L1 and needs a small negative value there that will again fall bellow the “min current” of the grid meter itself.
I’m noting more instability on my system for real 0 values (per phase) as well. If my load however is asymmetric in a way, that the result at the grid would be -1000 / 500 / 500 for example, the saldated “0” is quite stable. (Because that comes down to current values per phase, where the meter itself is reliable and quite stable on readings)
Please excuse my ignorance, but why does it keep nicely -20W during normal ESS (DESS off) if this is purely hardware related?
I’m currently diving into the dynamicess.py to find some code pointers, combined with some parameters I’m currently trying to log live in nodered.
I’m guessing the charge-rate is calculated incorrectly somewhere in this script. I do see some calculations where the efficiency is taking into account. Although I set the efficiency at 80% …
When the reactive strategy is 14 (=SELFCONSUME_NO_GRID), it is holding the grid setpoint quite nicely (bouncing around 0W). When the reactive strategy is 11 (=SCHEDULED_CHARGE_FEEDIN) the setpoint is not respected as shown in my screen captures.
Strange thing is that the code suggests it has a solar surplus and allows feedin (I guess to push excess to grid). I guess this proves that the charge rate is not calculated correctly in this case.
On the other side I have to figure out why it says available_solar_plus > self.chargerate and is pulling energy from the grid … in that case there is something incorrect in my settings…
Because of your knowledge of the code: here is some behavior and debugging I tried on my side. I’m not a programmer at all, but I try to find my way in code .
Except the fact there is some ‘idle’-losses so the target SoC = 56,1%, and actual SoC with rounding = 55%, it claims that we are “behind of schedule”. I do get that part. Though there is no other strategy-incentive to charge the battery: only self-consumption and all excess to grid.
At rule 1243 it calculates the charge rate, which is calculated based on start and end soc and remaining time etc. Because I have charge limits sets, I’m assuming it will use the calculated chargerate (which will be the lowest compared to both) instead of the battery charge limit.
This charge rate is passed on to the charge function. As far I understand (see nodered Flag node in my video) fast charge is NOT requested (flags = 0) and I have no DC linked solar. It’ll just set setpoint to None, ForceCharge to 1 and MaxDischargePower to -1. It’ll use the previously calculated chargerate. As shown at the (end) of the video, the actual chargerate of the battery is around the max battery charge limit (+/-3400W).
Only reason I see for this behavour is that the update_chargerate() function actually did calculate a much higher charge rate then my max charge rate setting. But this charge behavour conflicts with the result of these nodes:
Because of the lack of programming experience I can’t wrap my head around of what is actually happening, and what the code/nodes in NodeRed are telling me…
You mind taking a look and guide me to the right direction?
Yes, because in that strategy, DESS aims to keep the intended battery charge rate for that window (for example 2 kW) and feedin everything above. Could be 1W or 5000W feedin.
So that - by its nature - won’t follow a static setpoint.
The scheduler usually chooses that to “slow charge” the battery a bit and defer charging into hours of lower feedin prices.
Your energy flow forecasts also indicate, that the scheduler aimed to only charge “a bit” from 11 to 13, and then push most into the battery 13 to 15, when your feedin gain would be lowest.
So, with the example values provided, that means: 569W chargerate was the needed rate to comply to the schedulers window target soc goal - everything else (in that case 992-568) was intendet to be feed back to the grid due to better prices than later.
.
