While it was valuable during initial development, the current VRM implementation already offers way more functionality (e.g. Octopus (UK), Tempo (FR) and Vario (CH)) and is better kept up to date.
The VRM-API node seems the better alternative, though that one still requires some changes to be up to date as well. The idea is there to keep the configuration of Dynamic ESS in VRM (and partly in Venus OS), while the scheduled can be retrieved, altered and filled using the VRM-API node and the Dynamic ESS node that comes with node-red-contrib-victron.
Also the 15 minute interval changes havenât been looked into for the Node-RED implementation, while they are already done for the VRM implementation.
If you are using the current implementation, Iâd like to hear your specific use-case for not just using the VRM implementation instead.
Initially I was working on something resembling DESS myself but Victron was quicker to release
Currently Iâm on VenusOS v3.55 and running a more or less Hybrid DESS setup, using the VRM-API in Node Red, Dognoseâs DESS Hack (scheduled to be included and improved in v3.60 iirc) and some custom Node Red voodoo.
Among the things Iâm overriding:
forced grid consumption / charging at negative grid prices
scheduled charging at low grid prices to anticipate a large load later (charging my 22.5kWh electric motorcycle mostly)
manipulating grid target (depending on grid prices, anticipated load & solar forecast etc) to force consumption from grid and all solar to the battery
triggering external actions
The VRM API is thus very much appreciated.
Even though Iâm currently not using the Node Red DESS implementation, it could be useful for the very special cases where the VRM version is not compatible with certain overrides (in future versions).
Or is simply down, as occurred a few times.
Granted, the Node Red version also needs internet for prices and load/solar forecasting - but that can be worked around.
A use case there would be Privacy, for people who run offline and/or donât want to send data to a processor on the internet.
In Portugal both solutions are not ideal, since the dynamic energy prices could have different different âfixed valuesâ depending on the time of the day. The NodeRed solution do a better fit but I loose the predicted energy prices, the VRM one doesnât support this scenarios.
If in VRM we have a mix of the Fixed Price and Dynamic Price solution it would do the job: define custom formulas depending on the time of the day.
@BartChampagne could you share some of that node red voodoo?
Iâm just starting with node red (see : Dynamic ESS: manual set energy price for each hour - #7 by UpCycleElectric) to automated a boost charger on our trade (test) installation.
Next step concerns the phenomenon that in the morning before new pricing becomes available, prices already tend to be low a few hours earlier but DESS wonât start charging because it does not see any selling opportunity beyond midnight. And once pricing roles in is too late to charge up for it.
Iâm reluctant to share my voodoo âas isâ , not because I donât want to share but more because itâs (in my opinion) a bunch of clunky and messy code that I should clean up & rewrite some day when I have spare time.
It all works for my specific setup but I have no idea nor can I guarantee how my code will respond to your setup.
I have some very clean & nifty code as well but that code was paid for by a customer so I canât just throw it out in the open.
If you can elaborate on what youâre looking for specifically, I can check to clean up that part of my code before sharing it.
If youâre looking for a Node Red example to force charging from the grid, itâs a tricky one these days.
To achieve that on v3.55, my implementation requires The Hack to be installed, then it (ab)uses the âCustom Controlâ node to write to the com.victronenergy.settings'|/Settings/DynamicESS/AdhocChargeRate entry - just like you would do in GUI v1.
Since the entire DESS mechanism will change in soon-to-be-released v3.60 and The Hack will no longer work on that version, Iâll need to rewrite my code anyways.
And if youâre just starting with Node Red, I suggest you learn it first by making baby steps before importing unknown and complex code.
With regards to Dynamic prices: itâs called âDay Aheadâ market, so you should get prices for tomorrow not much later than 14:00 today.
If you only get your prices on the day theyâre intended for, youâre either not working on the Day Ahead market or thereâs something off with your data source.
The âlook aheadâ window jumps from about half a day to one and a half day around 13:00 when new prices roll in.
On many days the âmidday low priceâ window runs somewhere between 10:00 and 17:00
Every morning DESS trade plans to charge the battery midday but only to the level that it knows it can sell back profitably within itâs known look ahead window, which is upto midnight that same day until the new prices roll in.
Therefore DESS typically misses the opportunity to charge up much more in the late morning, not aware of the sell opportunity the next day early morning.
And by the time to the new prices roll in, itâs too late obviously.
So my question is, how can DESS be made aware that there is a reasonable and quite stable additional sell opportunity within the next 24 hours, in the morning?
One solution that I think would work reasonably well, is to extend the look ahead window to always be 24 hours ahead at least, and populate the hours for which actual prices are missing, with estimated prices, just a copy of the same hour from the previous day before would already be good enough. And by the time the new actual prices roll in, there is still plenty time for DESS to adjust accordingly.
If possible, at 01:00 in the morning, when the look ahead window is 23 hours, extend it to 35 hours by adding last days pricing to the end of the look ahead window.
The thinking being that history might not repeat, but will usually rime.
Alternatively, the same could be done every hour, always keeping a full 36 hour look ahead window available.
And also instead of copying the hourly price from the day before, simply populating the âmissingâ actual prices with the âlast price knownâ could also work. Anything, even a âbad estimate priceâ, is better then the current âno price knownâ situation.
âŚ
Edit: adding 8 hours of the âlast known priceâ at midnight as an intelligent guess looks pretty promising to me. As can be seen in picture below. By the way, these are crazy prices this weekend: minus 28ct to charge the battery, with taxes and costs, wow.
