This doesn’t work anymore, that’s for sure:
And since this was up to now the ‘adviced’ way of extracting prices from the schedule (object), all that uses those prices, breaks.
I had to revert to 3.70~41 due to lack of time to figure out a new way to get it all working again.
Ah yes, the update breaks the installation stats for DESS (only).
Adjusting to Installations → Fetch Dynamic ESS Schedule should be the only thing needed to adjust on the flow.
I actually tried that but it didn’t work and I don’t have the time to investigate. Most likely this has to do with storing the return object in the global context and our flows extracting what they need from that object.
That ‘only’ is in the eye of the beholder, assumptions being the mother of all f#€kups I suppose 
I’d be interested in giving it another try if you can provide some pointers as to what other ‘unintended’ consequences need to be taken into account. See above for one example: using the API call’s return object stored in the global context before processing the data (object/arrays) in various function calls in our flows. But better would be to re-instate the original API call for backward compatibility, I mean, why remove it?
And on a related subject, could I ask the two of you @dognose and @dfaber to have a quick chat amongst yourselves, as to why the DESS scheduler is perfectly capable of returning float precision SoC% values for every 15 minute schedule block while at the same time the DESS execution process insists on truncating those SoC% values to INT?
Yes, as a side-effect, that moved under installations[“fetch-dynamic-ess-schedules”] now in the global context.
Ok, but is the object structure still identical then? I mean, how deep will this rabbit hole go?
For maintainability and clarity. If we have both in, we will get questions on which one to use.
The object structure is still identical, containing records, totals and success.
Regarding the SOC precision, we are looking into that, keeping in mind that most BMS’es aren’t that precise in reporting SOC.
Yes I understood that to be the case. But please keep in mind that this is not an issue for large capacity systems in combination with Node-RED based control (/modifications). We already re-calculate SoC% based on the BMV Smartshunt provided ‘consumed Ah’ values, our internal SoC% counter has a precision of ~0.005% (0.1Ah/2000Ah).
I have not (yet) checked the Node-RED virtual battery implementation to accept float SoC% values but I would argue it to be an obvious improvement to make it so if it doesn’t already.
Not before you are getting questions on why the old one was removed, as in, right now
Array granularity/length identical as well? Not changed from hourly to quarter hourly? The devil is in the detail when we need to run through all our function nodes that make use of the old global store object. Hence my reference to the depth of the ‘rabbit hole’
The data for this endpoint is always in 15-minute buckets. If the buy or sell contract for the site is set to hourly, 4 subsequent 15-minute buckets will contain the same prices.
If that changed depends on the initial settings of the stats node.
So we are talking about the following changes so far?:
We could argue whether that’s a small change or not but that’s a bit besides the point, maybe we can agree it would be worth while to document such changes and refer to that in the change logs in the future?
I find the change causing this a little confusing:
BACKWARD COMPATIBILITY FIX FOR DEPRECATED dynamic_ess STATS ENDPOINT
The old victron-dynamic-ess node is being deprecated (https://vrm-dynamic-ess-api.victronenergy.com) How does that relate to the dess installation stats?
I am loss here. No matter what I do, I cannot even extract the current price.
Getting battery SoC will onluy provide history, albeit in 15 minute time slots
Old installation stats provides hourly time slots, starting at midnight NL (UTC+2)
Fetch schedules provides hourly timeslots, shifted to UTC
not sure how to respond to this. And yes DESS settings and prices are 15 minutes.
I find it very suspect that the fetch schedules API call URL, calls for “interval=hours”:
“https://vrmapi.victronenergy.com/v2/installations/xxxxxx/stats?type=dynamic_ess&interval=hours&start=1760745600&end=1760918399”
AND uses the exact same URL as the old installations stats:
url: “https://vrmapi.victronenergy.com/v2/installations/xxxxxx/stats?type=dynamic_ess&interval=hours&start=1760738400&end=1760911199”
The prices are stored in the deGs (Grid sell) and deGb (Grid buy) arrays and not in the Gc (grid cost) array. The latter stores the actual total price you paid that quarter/hour.
You are missing the point: the VRM-API Node is broken, no matter what schedules you request. It doesn’t fetch the 15m scheduling object as required. Unless of course you do what you did and bypass the Node with a completely self constructed custom query input, in which case you don’t even need the node at all. And all that was needed was the original VRM-API node to adhere to the set pricing time slot duration of 15 minutes or an hour (or any other duration for that matter). I mean come on, if the voluntary beta testers are becoming the first line of verification, we must be able to tell it as it is, no use in sugarcoating it.
Just updated Cerbo to 3.70-49 but didn’t yet figure out, how to get current price? I only get 46 values in deGb with vrm-api 0.3.6, where as in my Raspi with older vrm-api I get 95 and the last one is the current price.
