Let me start by saying that you guys (and galls) at Victron are doing a hell-of-a-job! So, thank you all!
For reference, my setup: 3 x Multiplus II 6k5 (1 x GX, 2 x regular) in 3-phase-setup, 4 x 16kWh LiFePO4 batteries, 9kW PV, 3 x 40A grid, ~1kW base load, running Home Assistant as orchestration layer for my home (automation is binary: it can’t be done half).
Where (my) HA has tons of information that may lead to optimal goals or decision directions, I trust GX better for execution. Hence, I would like to see my HA as Policy Engine, setting strategic boundaries for GX/VRM/DESS as the Execution Engine. Such abstraction would require clear segregation of duties though. That is where my questions originate and my requests aim at.
in my view, the main parameters needed to financially/economically optimise an ESS system are:
- PV production (in timeslots, over time)
- Consumption (in timeslots, over time)
- Grid pricing, both import and export (in timeslots, over time)
- Target battery SoC and horizon
- Other system parameters you already have
Ad 1: where my location alone provides guidance, the orientation and inclination of my panels is of the essence to predict my PV production accurately. Being able to upload something like a JSON with PV forecasts, in time slots for every x mins, with a y hrs horizon, would be very helpful for increased accuracy.
Ad 2: the (positive) effect of being able to indicate/upload expected consumption is depending on the model used for DESS. In the case of LP, prediction becomes key, while MPC would allow more for real-time adjustments. Question is: what kind of optimisation algorithm does the current implementation of DESS use - and, would you be open for (future) real-time adjustments to increase accuracy (and if so, how)?
Ad 3: dynamic energy contracts come with not-always-easy-to-understand pricing. Hence, if one has an accurate pricing provider, it would be helpful to be able to upload these prices (24 or 30hrs in advance) as to ensure DESS uses the right prices for its decision making.
Ad 4: I would say that for me, given the right pricing info and knowing my key system parameters, I would like to steer on ‘Target Battery Soc’ for a given horizon. So, if the other conditions are met, I would only like to be able to set a Target SoC every z hours, and let DESS do the rest of the magic: HA as the Policy Engine, Victron as the Execution Layer.
Ad 5: I think through VRM/GX/… you have all other necessary parameters at hand. If not, more than happy to discuss 
Concretely, in respect to DESS, I would like to understand:
- can ‘schedules’ be influenced externally, and if so, how?
- can (external) prices/costs be injected, and if so, how?
- what part of the optimisation occurs locally (internally) vs Cloud?
- to what extent is the optimisation MPC-based, or MPC-like?
- what is the DESS optimisation frequency?
- which forecast does DESS use exactly, for what function?
- is it possible (and if so, how) to influence the consumption forecast - and if not, what forecast is being used, and how do deviations influence any outcome?
My main questions would be whether an architecture that separates Policy from Execution (in a direction as indicated) finds solid ground.
Many thanks for any answers you can give!
