Hello, is it possible to “help” the Victron ESS by providing it with details of the loads being used (EV, air conditioning, swimming pool, DHW, house, etc.) from the Ekrano via Node-RED, or to indicate what the relays controlling these loads correspond to?
The details of the loads are not important for regulating the equilibrium point (ESS).
On the other hand, Opportunity Loads are currently being tested and could be available in a few weeks with the next firmware update. The idea is to switch a relay on or off depending on the surplus energy being exported to the grid.
Without passing judgement on this feature, which I have not yet tested, controlling certain loads using Node-RED programming is reliable and highly customisable. However, it requires programming skills and learning the Node-RED environment. Typically, a hot-water cylinder should be heated using surplus PV generation when there is enough of it, and during off-peak hours from the grid when there is not enough. But depending on consumption and the size of the hot-water cylinder, heating during off-peak hours may be unnecessary and counterproductive, because the day’s and the following day’s PV generation will be sufficient. I am curious to see how Victron’s engineers will have solved this problem.
As far as the hot-water cylinder is concerned, solar diverters are available that can perform this function, but why invest in one when a little programming is enough to solve the problem?
As for the EV, I think the Victron charging station integrates perfectly. For the others, controlling them by switching a relay on or off seems to me to be the only solution. So Opportunity Loads could provide an answer.
As for air conditioning, it is not a good idea to cut its power, especially when it is running. It is preferable to control it remotely in order to manage its consumption (telling the indoor units to switch off, switch on, cool or heat). It is not simply a matter of changing a switch. I do not think this first version of Opportunity Loads will include such advanced, non-standardised functionality.
As for the swimming pool, this is a case that could be managed very well by Opportunity Loads, but the usual recommendation is to run it for a certain number of hours regardless of the weather. So on some days it may not run at all. Is that appropriate?
Exactly, I wanted to talk to you about Dynamic ESS.
I’m currently managing the automation for the hot-water system with Node-RED, the two EV chargers that are no longer “seen” as EV chargers (I had to remove the Victron charger because it wasn’t compatible with my vehicles and also had connection issues), and the pool.
Since it was commissioned in early August, I’ve been drawing virtually nothing from the grid (a maximum of 1 kWh per day), except for the one time I enabled Dynamic ESS. It thought I was going to run out of energy early in the morning and drew power from the grid during peak-rate periods.
My idea isn’t to ask ESS or Dynamic ESS to manage my loads, but rather to tell it what type of load is operating and for how long. The sole aim is to give it data so that it can refine its calculations.
DESS is enabled in the settings, but not enabled on the dashboard. Does it already take historical data into account?
Thanks
I gave up on DESS fairly quickly, as it isn’t usable in my case because the energy sale price is highly variable and completely unpredictable.
I think DESS takes your history into account, but I can’t confirm that.
DESS relies solely on the consumption forecast based on the history of the last 28 days, the PV generation forecast, and the energy costs for consumption, feed-in and storage. It doesn’t need to know which devices consumed the energy, or what future consumption has been planned (provided it can be planned). Periodically, it analyses all these factors and uses them to determine the action to take at that moment. In short, it’s fairly complicated, given the sheer number of variables. However, this approach allows the algorithm to operate autonomously. Naturally, it cannot predict changes in consumption that the user decides to make based on the state of charge or the day’s weather. As a result, some of its decisions lead to energy being drawn from the grid when this was not necessary.
The algorithm is not described in sufficient detail to allow users to understand how DESS makes its decisions. This leads to frustration when a user considers a decision to be wrong because it has incurred a cost.
In conclusion, DESS seems to me to be suited to users with stable consumption patterns or to users who do not want to adjust their consumption based on the state of charge or the day’s weather. It has the merit of providing a generic solution to a standard problem: minimising the total cost of energy consumption. It is certainly not the best solution for every individual case. It is up to each person whether to use this feature or not, or to develop their own optimisation algorithm.
Thanks, Quentin. I’ll give DESS a try soon.