Today I saw very strange behaviour on my system. Can anyone explain:
The schedule probably did this, to have enough capacity for the hours of negative prices.
Hence, during that time, your system could send all solar to the battery, avoiding you to have to pay for feedin, while still maximizing your solar yield throughout the day.
You mean during night? I could look at that in detail, but iâm quite sure, that your battery SoC is dropping faster than it should due to the calculated discharge rate.
Hence, your system will reach a certain target soc value to fast, probably every 15 minutes, and then switch to idle eventually.
That usually is caused by entering a âtoo bigâ battery capacity in VRM/DESS config. You probably went with manufacturers optimistic Capacity values there, rather than using the net capacity of the battery.
So, everytime DESS schedules your battery to discharge 4 % in 15 min, it actually reports to have discharged 4% after 12 minutes and then idles 3 minutes or something like that.
Tl;dr: lower the capacity setting in DESS to a value that makes this behaviour vanish.
(Also, having already degraded batteries ofc. Makes their real capacity smaller than what itâs labeled)
Hi dognose, thanks for your quick reply!
I can see what you mean, but the negative prices are known upfront so why did it not deplete the battery more during between 07:00 and 09:00 at a much better price! The system now also needed to sell surplus solar power at very low prices. The battery still had 50-60% SOC during that time. (my ess has minimal SOC setting of 10%).
I think the battery capacity setting (48kWh) is on the low side already (for 314Ah cells 3*16 cells). But anyway, if think it would be better to not idle, but reduce the discharge during later hours to avoid taking power from grid. (e.g. recalculate the parameters every hour)
That is a good question, and when looking âbackâ at data an easy to spot decission that would have been better.
Probably, during the morning hours, solar forecast was lower, and the scheduler calculated, that 60% SoC, so 40% remaining is sufficent to cover the two negative hours.
Then, as time passed, solar forecast went up, so the scheduler decided it needs more empty space than initially assumed, hence decided to even feed in at low prices to ensure you donât have to feedin while negative.
Forecasts always have some imprecissions and the further you âplanâ, the more they sum up. 1% deviation per hour is roughly 15% in ânow +10hâ. So, the schedule will be continiously re-calculated every 15 Minutes.
Assuming this is VRM DESS, the algorithm is targeting minimum SoC at the end of itâs known price schedule, before new prices come rolling in that is midnight of the same day.
This is not working very well for finding good buy/sell opportunities (trade) because DESS will not buy during the day (at low prices) to sell at night (at high prices) when it can reach that minimum SoC without doing so. And misses all next day trade opportunities completely until those prices roll in.
It may be a matter of opinion but my stance is that the DESS Trade algorithm is not fit for purpose until it incorporates better ways to actually trade on several strategies in a balanced way:
The effect of all this very much masked in a solar production oriented system but becomes instantly clear in a trade only system. It will just sit at minimum SoC all day until it is time (too late) for the new prices to roll in and attempt to buy what it can to sell later.
But even with solar it creates strange artefacts such as yours, my educated guess is that in that timeframe (11-13) the DESS trade algorithm does not acknowledge the (buy now to sell later) opportunity and simply defaults to dumping to grid what it can to get to minimum SoC at the end of the day.
If you are interested @marcelmol , I am looking for someone with a solar installation to test how my Hybrid DESS Trade Node-RED flow behaves with solar involved (as we can only test on our pure trade system). In itâs most basic form this incorporates a Node-RED flow that runs the Node-RED DESS algorithm in parallel (but not actually active) to VRM DESS just to make use of itâs b_goal_SOC and b_goal_hour capability (set to 85% at 18:00 hours for instance). Then use the hours set for charging by Node-RED DESS (that are not recognized by VRM DESS) to switch On and Off the VRM DESS âkeep batteries chargedâ feature. This is a minimal interference with VRM DESS that already resolved a lot of the strange trading behaviour.
What youâd need to be able to do is to get Node-RED DESS installed (but not activate, keep it set to âautoâ) and copy over all settings from VRM DESS. I can then provide the additional settings and basic flow (json) to import and connect to make it a hybrid DESS system.
It works just like setting âkeep batteries chargedâ manually every morning when prices go low, and turning that off when prices go high again, but then automated to decide on the optimal turn on / turn off hours of the day.
You could even start with just a simple timer in Node-RED to turn on âkeep batteries chargedâ at say 11:00 and turn off at 17:00 just to get a feeling for how that works out for your solar/trade system
Hi Jan, happy to test. Did not play with nod-red yet but was planning to sooner or later.
Iâm not on a dynamic price scheme yet, so currently just playing to learn what I can expect..
My ibase goal actually is to have the batteries filled as much as possible at the end of the âsunnyâ period and discharge during the dark based on next day forecasts to avoid and grid intake as much as possible, and to be high SoC again after next days soalr intake.
The steps you need to prepare are:
All reasonably well documented.
(a) My list of installed helper nodes (simply install what didnât come with venusos large, do any missing victron nodes last to prevent errors)
When done I can provide a simple test flow as importable json
That is not too difficult with the toolkit described in above post. You might even find that use case completely covered with Node-RED DESS alone but I try to avoid that âsolutionâ due to it being marked to be phased out in favor of VRM DESS. My assumption is that functionality currently available in Node-RED DESS but not yet in VRM DESS will be ported to VRM DESS but in the meantime I use a hybrid system to get the best of both.
And it helps immensely to have both running side by side (including the schedule forecast graphs of both respectively) to figure out what DESS is actually trying to achieve.
Here is a flow to set âperiodic full charge override (balancing)â by VRM-API.
Description:
Example of use: Set a reasonable maximum SoC goal and change the true and false input inject nodes to act as timers, for instance âtrueâ at 11:00 dayly, âfalseâ at 17:00 dayly.
PS donât forget to install the ânode-red-contrib-boolean-logic-ultimateâ nodes before importing this flow (and all other required for VRM-API).
EDIT (v0.2): I made a small change to check for maximum SoC (Target) being reached every quarter of an hour (One could modify this to check the âActualâ SoC as well, but that is for another day).
EDIT2 (v0.3): Included the âget statsâ API call in the input group (normally called in itâs own group in the parent flow). Now this flow should be âcomplete and functionalâ standalone.
Tip: The results of the VRM-API calls are stored in the global context, a good place to start to reviewing what gets set and retrieved.
EDIT3: I mistakenly noted that this flow switches the âkeep batteries chargedâ feature while it actually switches the âperiodic full charge override (balancing)â feature. Both would work but the latter has the added benefit that DESS remains active and the graphs stay visible during the (few) hours that this feature is activated to force charging the batteries.
Ok will look at this in the coming daysâŚ
In the mean time here are the forecast for today. Note that the installation solar forecast differs dramatically from the DESS forecastâŚ
Also the battery is not projected to be filled to 100% during the low price period while it can sell at high prices in the evening. This seems counter intuativeâŚ
The current DESS Trade algorithm simply targets minimum SoC at the end of the know price forecast schedule. I agree that is counter intuitive (for a âTradeâ algo) when there are obvious âbuy now sell laterâ opportunities within that same day even.
Today you can try manually disabling âbattery balancingâ / âkeep batteries chargedâ (same thing) in the morning, enabling it (set to every 2 days) right before 10:00 and disabling it again right before 18:00 to see what the effect is.
Canât comment on the effect the solar production and unusual energy prices (big difference between buy and sell?). We use tibber dynamic prices where buy = sell. In general I think it best to set all settings as close to reality everywhere and let DESS do itâs work based on actual energy and battery costs.
Something to keep in mind is that a trade+solar system likes more battery capacity : prices are lowest when the sun shines hardest generally. DESS should (in theory) be aware that solar energy carries no marginal cost and only charge up from grid what solar canât provide for free. And IMHO best with a dayly SoC target of full batteries around dinnertime
On our system we use the Node-RED DESS algorithm (running parallel but not controlling the scheduling itself) to decide when to turn on and off the âperiodic full charge override (balancing)â setting (in VRM DESS). It has a function (missing in VRM DESS) to set an additional b_goal_SOC (95%) and b_goal_hour (18:00) target for the day and then calculates when best to start charging during low prices. (is there any reason why this is not enabled in VRM DESS while it works in Node-RED DESS @dognose ? Enabling this, even if only by API call, would make a big difference I believe (but much more elegant by enabling the scheduled charge levels while running DESS). And on another note: is there a way other than polling stats every 15m to get a push message when the schedule gets changed/updated at the VRM-API endpoint?)
Without that, we would have the same problem:
And this is the result after enabling âperiodic full charge override (balancing)â from 12:00 (automatic On by Node-RED DESS trigger) until 14:00 (automatic Off after pricing for next day rolled in AND target SoC above 70% as was our current setting). As visible, VRM DESS is continuing to charge even with âperiodic full charge override (balancing)â Off because it now targets minimum SoC for the end of day tomorrow (instead of today). From here on: Rince and Repeat.
The rational for this âinterventionâ is to enable DESS to start charging already before the ânext dayâ pricing schedule rolls in (between 13:00 and 14:00 normally. Without this intervention DESS will always miss all buying opportunities before the next day prices are available, which is a significant opportunity miss if not corrected for.
It would be nice if VRM DESS could also take in consideration b_goal_SOC and b_goal_hour for the next day, as visible in the Node-RED graphs. But that isnât a hard requirement because come tomorrow it will simply get triggerred to enable âkeep batteries chargedâ at the optimal moment again:
That said, the charm of this workaround is (IMHO) that it interferes minimally with the regular operation of DESS: only during those hours before the new prices roll in it may (or may not) nudge DESS to start charging a couple of hours earlier. The rest of the day it doesnât interfere with normal DESS operation at all. I hope this will make it suitable for systems with solar involved as well, or even in combination with DESS Green (instead of Trade) but I have not tested with either yet.
Let me know when so I can post the latest version.
I installed the 0.3 version. Not sure if I configured it properly but will see (also send you an email that I found in the 'Phasing out⌠thread). If you have a newer/better version please let me know s I can install itâŚ
That should work. The true / false âinjectâ inputs can be edited to âfireâ at preset times, thatâs a good starting point. I tried to keep most logic transparent by using nodes instead of functions with code for better visibility. Once you got VRM-API working and figured out where to find the debug window and the flow / global context variables you should be able to just âfollow the flowâ and investigate what the nodes do. All is pretty well documented in the help system for all those nodes.
The flow polls VRM-API every 15 minutes to get the latest schedules (adjusted hourly for actual solar production too I believe).
Then it proceeds to check the SoC target of the current hour (with PFCO enabled) . If that target is above a set minimum and the new prices have rolled in, the flow does not wait for the âturn offâ (false) input signal and disables PFCO straight away. Be aware the it can take a few minutes (to an hour max?) to see that reflected in VRM (dess settings and graphs) again.
From the settings you already showed Iâd advise to revisit all your other VRM DESS settings and turn restrictions off and set any settings to actual values as much as possible. I saw a big difference between buy and sell prices with a low battery cost, unless that is actually the case you can better adjust those to correct prices and higher battery cost.
Let me know what works, or not, and post your settings when you have questions. Next step is to get Node-RED DESS involved to choose when to turn on and off PFCO.
It is not improving.
Changed to green mode. Limit discharge to 4kW.
Why again limit discharging to 59% at high speed (it is asif the 4kw discharge limt is seen as a fixed discharge rate when DESS thinks it needs to discharge.) during the first hours of the night and then needing to get energie from the grid! This is costing me a lot, relatively. Sell price is much lower that buy price, so why not distribute charging across the night hours?
The reason for using batteries and DESS is to limit taking energy from the grid as much as possible!
@UpCycleElectric I run your flow and sat pfco between 11:00 and 17:00. The flow does not have any other impact on DESS behaviour, doesnât it?
No it basically just turns balancing on and off like you we could do manually in the DESS settings. The usefulness lies in the decision logic that then drives the timing/scheduling thereof.
I am currently rethinking how to better approach this DESS adaptation effort. Will at least refactor what I have into a general toolbox making use of some new functions of the upgraded node-red version in beta v3.70~5 and hoping to get a little more insight on the DESS roadmap from the devs as well.
For our trade only (no solar) system it now works quite well using two criteria to start a charge run: price being lower than half of the âbattery cycle costâ below the dayly price average AND then timed to the optimal low price âwindowâ of that day by shadow running Node-RED DESS (DESS mode still âautoâ: VRM) with a high 18:00 SoC goal. The latter allows to read when Node-RED DESS would start charging and thus VRM DESS will start charging if, as mentioned, the price is low enough.
More as a general note: a trade only system is much more predictable than one with solar or irregular large consumption events (EV charging f.i.) involved. In the end I think an update of or addition to the two DESS modes (Green/Trade) is unavoidable to really get this working well (enough) for a larger variation of use cases. Time will tell, I hope Victron will consider open sourcing parts of the VRM/cloud scheduler to facilitate that.
By the way, there are many ways to force the system to charge, from the things I tried an automated toggling of âperiodic full charge overrideâ a.k.a. âbalancingâ worked best with the least impact on normal operation but here are some other settings that could achieve sort like effect:
For now I am focussed on an on demand (to be automated by the user in Node-RED ) ânudge DESS in the right directionâ approach to try and keep best of DESS albeit with more control over it.
And Iâm still learning, just like the devs I suppose. Itâs still early for DESS, things will certainly mature to much higher levels of âuseability, predictability and profitabilityâ in the future.
Thnaks for your thourough coomets Jan.
Happy te test your developmentsâŚ
Coming tuuesday my dynamic price contract will be active so then I reaaly like to have somethin that limits grid intake.
I tried looking for flows that just discharges the batteries during the evening/night to a level it can be recharged again to 100% with solar production (and taking expected consuption into account off coarse). So indeed a sort of middle etween trade and green modeâŚ
Anybody developped such strategiy in node-red?
