victronenergy/dynamic-ess

Dynamic ESS

A Node-RED flow that uses VRM forecasting and algorithm to optimize when to sell, buy and hold the grid to zero. For use in systems that have hourly day ahead prices, which is the case in a big part of Europe.

Note that this is a proof-of-concept. Do check the about and disclaimer below for more information

If you are upgrading, make sure to read the RELEASE-NOTES.md file as well.

Prerequisites

In order to successfuly use this node, installations must:

• Be an ESS (Energy Storage System)
• Have a dynamic energy contract
• Not use generators
• Not be mobile
• For best results:
  • Have 28 days of operation time
  • Have location set for at least 28 days
• Run at least version 3.10 of Venus OS (latest or candidate)
• Not be running the VRM implementation of Dynamic ESS, as this will bite each other. The service com.victronenergy.settings and path /Settings/DynamicEss/Mode is used for this. Mode 1 (auto) is used by VRM. Mode 4 (Node-RED) can be used for Node-RED implementations.

QuickStart

• Install the following nodes via the palette manager:
  • victron-dynamic-ess
• Set your sites location in VRM.
• Import the fetch-dynamic-ess flow..
• Configure the Victron Dynamic ESS node.
• Deploy the flow and check the dashboard.

All of the parts are written down in more detail below. If you use this and have questions, issues and/or suggestions, please ask them in the Node-RED space of our community or file and issue on the GitHub site.

Installing required nodes

From the palette manager, install the following nodes:

• victron-dynamic-ess

Below is a short screen recording showing how to install them.

Node-RED also has documentation on adding nodes.

Set your location in VRM

Make sure that you set your sites position correctly in VRM, as that is used for determining the predicted solar forecast. This can be set under Settings -> Set location in VRM for your site.

Importing the fetch-dynamic-ess flow

Import the fetch-dynamic-ess flow (ctrl-i). Once imported, double-click the Dynamic ESS VRM node and fill out all required fields.

The imported flow looks like this:

Note that there also exists another flow that you can import: fetch-dynamic-ess-with-average-price-switching.json. This flow shows how to switch on/off a relay based on the average (dynamic) price.

If you want to link to the site from a dashboard node, you can simply add a template node that links to the site:

[{"id":"46b70ef9a19626f0","type":"ui_template","z":"ccbcca84c2779cd2","group":"ab8b2a192b041af5","name":"","order":0,"width":0,"height":0,"format":"<a href=\"/dess\">Dynamic ESS</a>","storeOutMessages":true,"fwdInMessages":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":860,"y":860,"wires":[[]]},{"id":"ab8b2a192b041af5","type":"ui_group","name":"Dynamic ESS","tab":"cc1a49b54f71c790","order":2,"disp":false,"width":"20","collapse":false,"className":""},{"id":"cc1a49b54f71c790","type":"ui_tab","name":"Dynamic ESS","icon":"dashboard","order":1,"disabled":false,"hidden":false}]

Configuration of the Victron Dynamic ESS node

Double click the Dynamic ESS VRM site to open the edit panel to configure the node. The following fields need to be filled out:

• VRM token - The VRM access token. See below on how to create one for your site.
• VRM portal ID - the VRM Portal ID can be found in the menu Settings -> VRM Logger and on VRM under the Device list -> Gateway. It looks like this: c0619ab27f32
• B_max - Battery capacity (in kWh)
• tb_max - Maximum Battery charge power (in kW)
• fb_max - Maximum Battery discharge power (in kW)
• tg_max - Maximum Grid Export power (in kW)
• fg_max - Maximum Grid Import power (in kW).
• Battery cycle costs - Cost of charging and discharging battery (in €/kWh).
• Feed in possible - Can you sell back to the grid?
• Feed-in control - Allow control over the feed-in variable (turn it off automatically when the prices are negative)?

Battery cycle costs indicate how expensive it is to do a cycle of charging and discharging the battery, ex pressed in €/kWh. A typical calculation for this is:

costs for buying the battery in € / (charging cycles * battery capacity in kWh)

One battery charge cycle equals full battery charged to 100% and fully used to 0%. If you only use half of the battery power, then recharge it and repeat it the following day — it will also count as one charge cycle instead of two. The number of charging cycles is a number that differs per brand. The battery costs is usually somewhere between € 0.02 and € 0.06 /kWh.
Some feedback of users is that they don’t care about the battery costs, as they already paid for it, so technically there’s no additional costs to charge it. In that case we still advise to put a small amount in as battery costs. E.g. 0.01 €/kWh.

The other thing to configure is the buy price formula and sell price formula (if you are allowed to sell back to the grid). This formula looks typically something like: (p+0.02+0.13)*1.21. It this example it breaks down to:

• p - the dynamic price / kWh
• € 0.02 - energy provider profit share
• € 0.13 - DSO working price + contributions/levy/taxes
• 21% - tax

The sell price formula looks often identical and in common cases looks something like (p-0.02+0.13)*1.21. So the energy provider profit share works the other way around.

With different providers, the formula will likely be different. So this does require some research on how your pricing is build up.

The default filled out values are typical values. If you think you are factors of, you might want to consult on the community and ask for advice on what to fill out.

Once everything is filled out, you can deploy the flow and check https://venus.local:1881/dess/ to see how the system will take its actions for the day.

Used dbus paths

When correctly deployed, these nodes do write (and read) from the dbus (using node-red-contrib-victron nodes). The following services and paths are being written to:

• com.victronenergy.settings /Settings/DynamicESS/Mode - The mode of Dynamic ESS will be set to 'auto'
• com.victronenergy.settings /Settings/DynamicESS/Schedule/*/* - Depending on the used flow 1 or more schedules are written to, containing the desired Soc, AllowGridFeedin, Start, Duration, Restrictions and Strategy.

Graphs

On each input, the flow generates fresh graphs, which are displayed on the https://venus.local:1881/dess page. Light gray background on the charts display the recorded values, while the transparent background shows the estimated/planned values. The darker gray part designates the current hour.

As soon as the new tarrifs are available, the mode will change from 24 hours into 48 hours.

Usage

As the information is being retrieved via the VRM API, a token is needed to be able to get the required information. This token will then be used instead of your VRM credentials. See create an access token below on how to do that.

While it is probably possible to deduct the country based on the longitude and latitude, it is a lot easier if you fill it out yourself. So you will need to fill out the country as well. This information is used to retrieve the current energy price from ENTSO-E. ENTSO-E is the European association for the cooperation of transmission system operators (TSOs) for electricity. All EU countries use this as source for determining their next day dynamic energy prices.

Create an access token

In order to use the dynamic ess node, you will need an VRM API access token. Creating such a token can be done from the VRM site. The process is described below.

Go to the access token part of VRM and add a new token. Name the new token Node-RED dynamic ESS or something that your mind will link to dynamic ESS. Once generated, store the access token in your password vault as you won't be able to retrieve it again. You will also need to fill out this token in the dynamic ess node.

Troubleshooting

The node fails with the message cannot create feasible schedule

Make sure you have the timezone of your GX device set to match the timezone of your country. If that does not match, it cannot create a feasible schedule (and thus reports that). So go to the (remote) console to Settings -> Date & Time -> Time zone and set the correct time zone. Note that a restart of Node-RED will be needed as well after changing the time zone. This can be done either by rebooting the system or disabling and enabling Node-RED via the menu.

The battery discharges less and less each day

You probably have the battery set to Optimized (with batterylife). As long as the battery does not reach 100% state of charge (which it probably does not reach while running Dynamic ESS), it will increase the Active Min SOC each day by 5% until it reaches 100%. This gives Dynamic ESS less space to play. At the moment Dynamic ESS has no way of coping with this. The current work-a-round is to either accept this behavior or set the mode to Optimized (without BatteryLife) and periodically disable Dynamic ESS and charge your battery yourself.

The console shows Dynamic ESS mode "Unknown"

As the VRM version of Dynamic ESS and the Node-RED variant should not be biting each other, both use different modes. Mode 1 is reserved for VRM, showing Auto, mode 4 is reserved for Node-RED, showing "Unknown" on the console. This is expected behavior.

The battery (dis)charges too slow to keep up with the target SOC

The Venus OS needs to know the battery capacity in order to make the correct calculation, which defaults to 2 kWh (if not set). The following flow adds setting the battery capacity from Node-RED. You can import this via ctrl-i / command-i / the import menu and pasting it into the red area.

[{"id":"11c0695b7819894f","type":"group","z":"9a54b4bbc1a25e38","name":"Store battery capacity","style":{"label":true},"nodes":["e9a9bebc9c4732d0","b48a8f507e14330a","b68ffdbbf4152cf3","8d723ea6a3f644bc"],"x":54,"y":899,"w":1092,"h":82},{"id":"e9a9bebc9c4732d0","type":"change","z":"9a54b4bbc1a25e38","g":"11c0695b7819894f","name":"battery capacity","rules":[{"t":"set","p":"payload","pt":"msg","to":"dess.options.b_max","tot":"flow"}],"action":"","property":"","from":"","to":"","reg":false,"x":260,"y":940,"wires":[["b68ffdbbf4152cf3"]]},{"id":"b48a8f507e14330a","type":"victron-output-custom","z":"9a54b4bbc1a25e38","g":"11c0695b7819894f","service":"com.victronenergy.settings","path":"/Settings/DynamicEss/BatteryCapacity","serviceObj":{"service":"com.victronenergy.settings","name":"com.victronenergy.settings"},"pathObj":{"path":"/Settings/DynamicEss/BatteryCapacity","name":"/Settings/DynamicEss/BatteryCapacity","type":"number"},"name":"","onlyChanges":false,"x":880,"y":940,"wires":[]},{"id":"b68ffdbbf4152cf3","type":"change","z":"9a54b4bbc1a25e38","g":"11c0695b7819894f","name":"to number","rules":[{"t":"set","p":"payload","pt":"msg","to":"$number(payload)","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":450,"y":940,"wires":[["b48a8f507e14330a"]]},{"id":"8d723ea6a3f644bc","type":"link in","z":"9a54b4bbc1a25e38","g":"11c0695b7819894f","name":"link in 1","links":["0a258a4a88409834","fa866313f9c8bebf"],"x":95,"y":940,"wires":[["e9a9bebc9c4732d0"]]}]

When correct, it looks like this:

Put it on the canvas and redeploy the flow. You can also check the set battery capacity by reading from service com.victronenergy.settings and path Settings/DynamicEss/BatteryCapacity (e.g. by using the custom input node).

My battery stays fuller and fuller each day

The system works with the minimum SOC. In case you have set your system to Optimized (with BatteryLife), the system will still try to get a full charge and increase the active SOC limit each day by 5% until it reaches 100%.

If Active SOC limit is larger than min SOC, then that is seen as the minimum SOC the battery can be in, hence the model tries to schedule with that limitation.

If you don't want this, set your ESS mode to Optimized (without BatteryLife) and make sure to charge your battery manually periodically.

Error message when importing: Imported unrecognised types: ui_template, ui_group and ui_tab

If you get this error, you will need to install the node-red-dashboard nodes first. This can be done via the palette manager. Alternative is to delete the template-node from the flow.

What this template node does is to create a link to the /dess url from the /ui page on your device. This allows you to access the Node-RED DESS implementation via VRM.

Other

Restrictions

Since beta release 3.20~17 there is a com.victronenergy.settings / Settings/DynamicESS/Restrictions field for setting certain restrictions to the system. Currently there are the following options:

• 0 = No restrictions
• 1 = No exporting from battery to grid
• 2 = No importing from grid to battery

The following flow can be used for that:

[{"id":"4ce5aae7de47bc94","type":"victron-output-custom","z":"a2d2c9f4739759d4","service":"com.victronenergy.settings","path":"/Settings/DynamicEss/Restrictions","serviceObj":{"service":"com.victronenergy.settings","name":"com.victronenergy.settings"},"pathObj":{"path":"/Settings/DynamicEss/Restrictions","name":"/Settings/DynamicEss/Restrictions","type":"number"},"name":"","onlyChanges":false,"x":810,"y":460,"wires":[]},{"id":"b823ba313cf1f7e6","type":"inject","z":"a2d2c9f4739759d4","name":"0 - No restrictions","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"0","payloadType":"num","x":300,"y":460,"wires":[["4ce5aae7de47bc94"]]},{"id":"b9a38621ba13bb0b","type":"inject","z":"a2d2c9f4739759d4","name":"1 - No exporting from battery to grid","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"1","payloadType":"num","x":360,"y":500,"wires":[["4ce5aae7de47bc94"]]},{"id":"3895c5f36826be0f","type":"inject","z":"a2d2c9f4739759d4","name":"2 - No importing from grid to battery","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"2","payloadType":"num","x":360,"y":540,"wires":[["4ce5aae7de47bc94"]]}]

Since candidate release 3.20~30 also per-timeslot restrictions got added. The latest importable flows support this. Note that the global restrictions have leading priority. So if that one is set to No exporting from battery to grid, the per-timeslot restriction cannot overrule that.

The algorithm automatically fills out not to import from grid to battery when the prices are too high. Wich is defined as: buy price > maximum sell price - battery cycle cost. In those cases the 2 restriction will be activated. Resulting in no longer punishing the grid when the forecasts don't match the actual values.

Strategy

From 3.30~7 there are currently 2 different strategies in use:

• 0 - Follow the target SOC
• 1 - Minimize grid usage / maximize battery usage

The system determines which of the strategies is best to follow during a specific hour, mainly, but not limited to, looking at price. Usage of these restrictions has been added to the importable flows.

System efficiency

The efficiency of the ESS system is considered (by default) to be 90%, meaning that if your solar yield is 10kWh and you put that in your battery, you are able to only pull 9kWh back out of it (for either consumption or selling to the grid). Note that this is not only the efficency of the battery, but also includes inverter losses.

It can be adjusted (since candidate release 3.20~17) via the com.victronenergy.settings / Settings/DynamicEss/SystemEfficiency dbus path. If you want to adjust it to e.g. 85%, you can use the following flow:

[{"id":"8d63274285babe24","type":"victron-output-custom","z":"a2d2c9f4739759d4","service":"com.victronenergy.settings","path":"/Settings/DynamicEss/SystemEfficiency","serviceObj":{"service":"com.victronenergy.settings","name":"com.victronenergy.settings"},"pathObj":{"path":"/Settings/DynamicEss/SystemEfficiency","name":"/Settings/DynamicEss/SystemEfficiency","type":"number"},"name":"","onlyChanges":false,"x":490,"y":220,"wires":[]},{"id":"0a6927f3647c0285","type":"inject","z":"a2d2c9f4739759d4","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"85","payloadType":"num","x":110,"y":220,"wires":[["8d63274285babe24"]]}]

About

The goal of Dynamic ESS can be formulated in the following way:

• Minimize the costs made on the grid and battery,
• By using the grid and battery to indirectly control the energy flow,
• While taking the consumption estimates, PV yield estimates, grid limitations, battery limitations and energy prices into account.

By taking the mentioned factors into account, Dynamic ESS builds a comprehensive model of the site to be able to generate a schedule of battery and grid usage for the installation to follow throughout the day to minimize its costs.

The algorithm does consider tomorrow's prices, consumption and PV yield estimates (from the moment tomorrow's prices are published). This is not expressed visually on the graphs because Node-RED implementation is only a proof-of-concept.

Disclaimer

• This is a proof of concept project. In the future this implementation in Node-RED will become obsolete as the functionality will move into VRM/Venus OS native.
• This flow uses control paths that may interfere with your normal GX device usage. It adjusts settings (setpoint) and will insert a schedule for charging in the ESS menu. If you don't want that, don't use this node. See below which dbus paths are being used.
• When the API gets updated, there is a fair change that the node also needs to be updated. The API will respond with a 426 / Please update http status code.

dynamic-ess's Issues

Limit hammering the API

Don't allow an update frequency beyond once every 5 minutes. The data won't update more frequent anyway and hammering the API will only cause extra load.

[Bug]: Active SOC value not working for mode with BatteryLife

Contact Details

[email protected]

VRM / Site iD

210204

Country / region

Czech Republic (cz)

B max

20

TB max

8.5

FB max

8.5

TG max

9.9

FG max

12

Battery costs

0.07

Buy price

(p+0.150675)*1.21

Sell price

(p-0.0276)*1.21

feed-in possible

• yes
• no

feed-in possible

• yes
• no

What happened?

Minimum OC is correctly displayed in NodeRED flow (currently 45%) but algo prediction and visualisation on DAshboard still counts with basic value and thinks it can go as low as 15% today

Relevant log output

No response

Screenshots

[Bug]: Unable to connect to VRM

Contact Details

[email protected]

VRM / Site iD

210204

Country / region

Czech Republic (cz)

B max

20

TB max

8.5

FB max

8.5

TG max

9.9

FG max

12

Battery costs

0.07

Buy price

(p+0.150675)*1.21

Sell price

(p-0.0276)*1.21

feed-in possible

yes

feed-in possible

yes

What happened?

Yesterday afternoon I have started to get message Could not get feasible schedule.
Today I have tried to disable DynamicESS node. Then turned off NodeRED Large OS Image functionality. Then turned it on again and tried to import DynamicESS nodes again
Got mesage that nodes already exist (they are seen in palette, but removing them again throws Not exist message).
I have imported flow, but getting Internal Server 500 mesage (started this morning).
Now with verbose mode on node I am getting improper properties and undefined mesages for request.

Relevant log output

No response

Screenshots

Why doesn’t Victron obey nodered schedule

I’ve installed Venus os large, node red, dynamic ESS. Charging according to schedule goes well, but discharge not. It sets to pv only not pv & battery. Again… why is this only with me when everyone is fine? Struggling with it for 3 months now ..

United Kingdom not available

Hi, just came across dynamic-ess but UK is not available, would you consider supporting please?

Thanks

[Feature]: Plan for car charging

Contact Details

[email protected]

Description

Dynamic-ESS has troubles foreseeing car charging. In fact it dumps the house battery during the evening and then at night, when I charge the car (23:30u and on) the house battery is empty and the charging is done from the grid. The house battery dump should have been done while charging the car.
I also charge the car sometimes during the day, when at home and the sun shines. There is no distinct rhythm for this.
Could you offer an approach for this?

• A link to my car, perhaps together with Jedlix?
• or, provide an advise (via vrm, app etc) about when to charge the car, for me to manually adapt the car charging schedule.
• or, would it be better to always charge during the same time in the night, assuming the dyn-ess algorithm will learn this.
• or any other advise?

(FYI I have about 40kwh nett capacity in the house battery)

Suggested Solution

Could you offer an approach for this?

• A link to my car, perhaps together with Jedlix?
• or, provide an advise (via vrm, app etc) about when to charge the car, for me to manually adapt the car charging schedule.
• or, would it be better to always charge during the same time in the night, assuming the dyn-ess algorithm will learn this.
• or any other advise?

Alternatives

I have no insight in the learning capabilities of the dyn-ess algorithm.
I could imagine that dumping the battery is postponed until the expensive hours in the morning (6-9am, or maybe longer) and never done during evening hours. In that case dyn-ess should offer an option to allow dumping to the grid only starting at 6am (only if room needs to be provided to catch the harvest from the sun during the day)

Additional Context

I have 40kwh net storage in the house battery. Typically charging the car will take 20-40 kwh. Sometimes more.
my house consumes 8-10 kwh daily, but this can double in winter

Unwanted Inverter Settings Changes in Solar Prediction Algorithm

I've noticed that the algorithm switches the battery to idle a little early as soon as it predicts that any sun will be coming out. I've attached a couple of screenshots of what I mean, please ignore 3am that is when my network updated. However, it correctly predicts (in my opinion) that it should use the batteries (showing the light blue on the energy graph) for the entire day, but when it comes to the time the sun starts generating electricity (6 am) switches the battery to idle. It still displays the blue until the hour is over, but already put the battery to an idle state. This is not an isolated incident, I've had it for the past three days, and it did the same each day.

The issue persists into the evening. As long as there is still some solar present, it keeps the batteries in an idle state, despite the electricity prices being at their high.

I unfortunately had to modify the node red flow a little to make it work with my system, I could see the issues coming from there. The "victron-idle-battery", integration does not appear to be working for me, therefore I used a flow to limit the inverter output from 0 to 3000 depending on idle or active battery state.

I also had to change the TG max and grid-set-point flow. For some reason when the battery is idle, it would set the grid-set-point to TG max. Therefore, when I wanted to interfere, there were a lot of settings for me to change. I was not exporting anyways through the inverter, therefore I changed the flow to only only have TG max 0 and a block filter unless values change. This way I could intervene without the system changing everything back straight away.

My apologies if this is its intended purpose, or if I broke the algorithm with my modifications to the node-red flow. It could be plausible that the algorithm was not meant for grid-tie micro inverters and my issues stem from that. I find this project really great and would love it to work. In the last screenshot, I already intervened to turn on the inverter. However, the system still wanted and still displays to keep the battery at idle.

Possibility to add ESS name to dashboard?

Would it be possible to add the dynamic ESS name on the dashboard? I have three Victrons to monitor, now need check URL everytime to see if i'm looking at the right one...

Sweden not selectable as a country.

Is there a reason why Sweden and Norway are missing in the country list?

"Error fetching VRM data"

I get this error, it states "Retrieving setpoint" and then the following error,

[Bug]: Could not create a feasible schedule

Contact Details

No response

VRM / Site iD

285851

Country / region

Estonia (ee)

B max

7.5

TB max

2

FB max

2

TG max

0.72

FG max

2

Battery costs

0.04

Buy price

(p+0.0044+0.0394)*1.2

Sell price

p-0.0075

feed-in possible

yes

feed-in possible

yes

What happened?

After enabling Dynamic ESS node the error "Could not create a feasible schedule" will be displayed. Api info output shows http 500 "Internal Server Error"

Relevant log output

No response

Screenshots

[Feature]: Support E10 UK - for example by inputting day ahead prices manually.

Contact Details

[email protected]

Description

I have an E10 tariff in the UK. This means that prices vary throughout the day in 6 distinct periods that run for different times. For me cheap rate 0430-0730, 1330-1630,2030-0030. These actually run from 24 minutes past. There is no way I could download this information for the day ahead.

Suggested Solution

Allow manual times to be injected with the prices for periods. Also the allow entering pricing or not in my case for the export.

Alternatives

No response

Additional Context

No response

[Feature]: Sometimes charge battery to 100% for a number of hours to balance cells

Contact Details

@SimonYoungtree

Description

once a month I have to intervene in the dynamic-ess, to make sure the battery is charged to 100% for a few hours. I do this to allow the batteries to balance and to reset the 100% SOC. Could dynamic-ess take this maintenance into account?

Suggested Solution

Allow to set 1 value: for how many hours per month should the battery stay at 100%. It is up to the algorithm to find the optimal window(s) to do so.

Alternatives

Put in a weekly charge schedule with a sufficient long time to charge to 100%. But this is sub-optimal.
Or write some rule in node-red to insert such a schedule once every few weeks when weekly is too often.

Additional Context

No response

[help]:

Contact Details

[email protected]

VRM / Site iD

48e7da85adab

Country / region

Austria (at)

B max

14

TB max

6

FB max

7

TG max

0

FG max

3.6

Battery costs

0.04

Buy price

(p+0.02+0.13)*1.21

Sell price

No response

feed-in possible

no

feed-in possible

yes

What happened?

Guten Tag

Hab den Flow wie in der Anleitung installiert. VRM Token erstellt, Tolle Anleitung übrigens.
nur der Baustein "VRM Dynamic ESS" hat ein rotes Quadrat [ object Object ] ich finde keinen Lösung ?

ich verwende keine Victron Batterie, kann das die Ursache sein ?

ich hab alle meine flow´s deaktiviert um sicher zu gehen das die nicht stören.

Relevant log output

No response

Screenshots

![DESCRIPTION](LINK.png)

Could something like this be used in a victron system that does not have ESS enabled?

Hi, nice repo I'm in the process of configuring my ESS system, however I may have to run the system not in ESS mode due to grid code and not wishing to backfeed to the grid. However this means I can't setup scheduled charging from my GX unit in the ESS settings. I was thinking I could manually switch my inverter from "invert" to "on" (invert + charge) at certain times of day when energy is cheap, but this is a lot of manual effort so I'd rather automate that process. Maybe that's possible simply with a relay that enables the charger between certain times of day, I'm not sure. Wondered if you'd have any thoughts on my situation?

[Bug]: Why only exporting in the hour with the lowest price

Contact Details

[email protected]

VRM / Site iD

287956

Country / region

Netherlands (nl)

B max

40

TB max

6

FB max

6

TG max

10

FG max

10

Battery costs

0.04

Buy price

(p+0.02+0.13)*1.21

Sell price

(p-0.02)*1.21

feed-in possible

yes

feed-in possible

None

What happened?

Yesterday between 14:00 and 15:00 the price was at its lowest (+/- p=-0.02). Only during that particular hour the system decided to export

Relevant log output

No response

Screenshots

![DESCRIPTION](LINK.png)

[Bug]: "need a victron config client" if this is the very first victron flow added to node-red

If this is the very first flow added to node red, the idle battery flow gives an error on the victron-idle-battery node:

"need a victron config client"

The Victron config client is only available when there is a Victron energy flow created before. After I added a flow with one of the normal Victron Energy nodes, the config client was created and the dynamic ESS flow started to work.

I don't know if this can be fixed in the ESS "victron-idle-battery" node, or that this must be added to the prerequisites in the documentation.

[Feature]: Battery temperature ceiling parameter for longevity batteries when price arbitraging large energies

Contact Details

[email protected]

Description

When the algorithm decides to charge the batteries it does so at the power settings set under ESS and DVCC
For some systems this may result in rather high battery temperatures being reached.
If not on the charging session then possibly on the discharge session thereafter.
Especially in seasonal countries it is not practical to manually adjust the ESS and DVCC power limits

Suggested Solution

In the event this is desirable (It is not always as per issue #30) it would be useful to allow the algorithm to throttle charging based on a maximum battery temperature parameter. Let's say 35 degrees Celsius. If charging started at 24 degrees Celsius and half way the battery temperatures are up to 30 degrees it would make sense for the algorithm tot throttle the charging power to not exceed 35 degrees Celsius.

Furthermore in the event the algorithm economically would like to price arbitrage a lot of energy in a short time window (charge + discharge) this may not be technically feasible without exceeding safe temperatures. As such it would be useful if the algorithm could learn the site battery units temperature dynamics and take them into account when deciding how much to price arbitrage in a certain time window to stay within temperature limits.

Even for and airconditioned setup it would be a good safety feature in case the AC broke down.

Alternatives

No response

Additional Context

Managing the price arbitrage energy flows based on safe battery temperature avoids excessive wear of equipment and allows for more system effectiveness than the current manual settings as manually one would need to leave more safety margin and thus forego arbitrage volume / grid stability contribution.

[Feature]: Consideration for car charging/diverting to hot water tank

Contact Details

[email protected]

Description

I am running my own dynamic ess solution that is highly tailored to my setup. There are a few things that might adversely affect the prediction based on historic usage. People will often charge their cars in the cheap period/sunny times in the summer. If this is fed into the historic data then the dynamic part of it will start to make incorrect decisions holding back battery and then not having any space to charge from solar. Other things that can also be high power but a bit random include diverting spare solar to hot water tanks and heat pumps.

I have a house hold base load graph that I work against and then display daily spare solar and battery SOC for the day ahead to let me decide if I charge the car or not. It is very difficult to automate as so many factors need to be considered. Car charge required, inefficiencies at low charge rate vs higher charge rate.

Suggested Solution

Is there some way of filtering consistent high power loads from the base load graph? At least then the future predictions are just the normal household use and the user can decide if they want to plug in the car or not? Its not terribly important for me as I'll continue to use my solution not least since I can't feed the prices in but its something that probably needs to be considered.

Alternatives

No response

Additional Context

No response

[Feature]: Throttling the charging and discharging when the price window is large enough to maximise system efficiency

Contact Details

[email protected]

Description

The algorithm goes full blast while charging and discharging regardless of the parameters set in the dynamic-ess node.
In some cases this may be fine but often the price windows to charge at low rates or sell at high rates are wider than the maximum charge and discharge times of my system. As a result the system efficiency is lower that necessary.
A full blast cycle drops my system efficiency from an average standard ESS score of 88.5% to only 77%.

Suggested Solution

Suggested solution is to make the price window time determine the charge and discharge currents to optimize efficiency.

Alternatives

No response

Additional Context

No response

Possible to manually select battery monitor?

My system is using the Multiplus for battery monitoring and SOC calculations because the BMS is junk and unable to understand when the battery is full so it's reported SOC is just slowly drifting down to 0. I still have the BMS connected though, as it is feeding cell min/max and eventual fault info to the Victron system. The dynamic-ess is for some reason picking up SOC from the BMS when it searches for battery instead of selecting the same battery monitor as already selected for ESS in the system (in my case Multiplus-II).

Is it possible to add an option to manually select what battery monitor is being used by dynamic-ess, or change the battery identification to match what is already configured for the system?

Battery to idle on 18%

SOC limit is set to 10% in console. Why is Node Red stopping discharging at 18% SOC? It go's to idle battery. Where can I change the minimum SOC in Node Red?

[Feature]: Fixed price Economy 7 in UK

Contact Details

No response

Description

Support for fixed price Economy 7 for UK customers.

Suggested Solution

I have a fixed price tarrif that runs between 1am and 8am UTC, where those 7 hours are cheaper, and the other 17 hours are less cheaper. I don't need any calculations regarding 'p' other than the fixed price.

Also, I'm having issues setting the system up as I run my Cerbo on UTC-7mins (my electricity meter has a fixed inbuilt clock to switch tarrifs, and it's 7 minutes slow from factory!). There is no UTC selection under the timezone/location setting in the NODE-Red setup options.

Alternatives

No response

Additional Context

No response

Reset setpoints when no connection can be made (to VRM)

In case no connection to VRM can be made, the setpoints should return to normal (as in before the node was deployed).

So the current settings should be stored and used as fallback, also indicating this situation via the status node.

Other countries not working

I setup the program as described, and filled out my data using germany as the country. However I was met with error, Error 500 Internal Server Error.

After multiple tries, I changed the country to netherlands, and it worked perfectly! As soon as I changed it to germany again, it did not work anymore. Does anyone have a fix for this please?

I find this project quite facinating. My current flow is very stupid, but it works. This project is so much better if it works!

Provide pricing information for more countries

I've been closely monitoring this development and we do plan to implement a dynamic ESS for Germany.
Currently, I can only call the API using country=NL, but I would really like to use EPEX Spot pricing for Germany to optimise the ESS system.

Is it possible to deploy a local backend service? We already have locally a home assistant solution running, recording all power consumption, pv production and running a PV forecast (via pvlib or solcast).

[Bug]: Part of "Consumption" should have been recorded as "to Battery"

Contact Details

[email protected]

VRM / Site iD

287956

Country / region

Netherlands (nl)

B max

40

TB max

6

FB max

6

TG max

10

FG max

10

Battery costs

0.04

Buy price

(p+0.02+0.13)*1.21

Sell price

(p-0.02)*1.21

feed-in possible

yes

feed-in possible

no

What happened?

The system does not register correctly what energy has been moved to the battery. It registers everything as "Consumption"
See the picture for the 12-13h period: Only Consumption is visible (blue line), while the majority of that consumption actually went to the battery. This is not visible. I assume by not recording the consumption correctly, future predictions based on history will also be wrong.

(10% Batt ~ 4 kwh)

Algo stops and starts at random moments

I have this working for 2 cycles now and nothing the algo does or calculates makes sense to me. Its now 23:00, batteries are not empty, why does it stop discharging?? Lowest is at 30% highest at 54% SOC. It does not look at the SOC at all, it just stops because the algo says its time to stop. For charging the same issue, when time is time it stops charging. Besides that the charging time calculation makes no sense at all. Tomorrow will post another printscreen from the charging chart. Attached is the chart of today but look at the timeline at 23:00. Why is it stopping?

[Bug]:

Contact Details

No response

VRM / Site iD

No response

Country / region

None

B max

No response

TB max

No response

FB max

No response

TG max

No response

FG max

No response

Battery costs

No response

Buy price

No response

Sell price

No response

feed-in possible

• yes
• no

feed-in possible

• yes
• no

What happened?

A bug happened!

Relevant log output

No response

Screenshots

![DESCRIPTION](LINK.png)

[Feature]: Rolling graphs rather than fixed for a single day until 00:00

Contact Details

No response

Description

Currently the graphs are day bound meaning the end at midnight and show progress during the days as grey areas.
Unfortunately these graps are always day based, so looking at it around 23:00 does not show any plans for after midnight.

Suggested Solution

Rolling graphs with 24 forecast rather than fixed for a single day until 00:00.

A better understanding of the generated plan would be a view roll in the hours of the next day including plan for usage and battery soc.
This would give much more confidence that battery SOC over the night is sufficient the cover the expected load until the sun rises.

The way I envision something like this is to have the graps having a slightly larger view with some hours visible in the past and always have the next 24 hours as 'planned'.
With each passing hour one hour from the past drops off from the left and one hour in the future is added on the right.

Expected usage, battery soc, PV forecast, loading schedules based on hourly prices etc.... can be rolled in as they become available.

With this when ever you look will have a 24 hour plans, even at 23:00 at night...

Alternatives

No response

Additional Context

No response

ESS doesn't discharge battery to grid

Hi,

I've setup the ESS, charging goes well according to the calculated schedule.

Discharging is not going well, the ESS sets the setting "self-consumption above limit" to "PV" instead of "PV & Battery".

If I change it manually it starts to discharge, until the ESS resets the settings.

Furthermore, the discharging is limited to 300 Watts, while the limits are set to 2000 Watts. I can't find this eather.

Where can I modify this?

Regards, Marc

[Bug]: last hour of day (23) from grid but never from battery eventhough there should be enough in battery

Contact Details

[email protected]

VRM / Site iD

314806

Country / region

Austria (at)

B max

No response

TB max

No response

FB max

No response

TG max

No response

FG max

No response

Battery costs

No response

Buy price

No response

Sell price

0.13

feed-in possible

None

feed-in possible

None

What happened?

Looks like the last hour of the day always imports from grid rather than from battery as the other hours do nicely.

Relevant log output

No response

Screenshots

![plan](https://github.com/victronenergy/dynamic-ess/assets/24240995/508b0f09-1044-467c-9c85-e8f447904711)

[Feature]: Individual Grid Setpoint that is not Zero

Contact Details

No response

Description

Hello, I think not all want to set the gird setpoint to zero. I think it's good that everyone can set their own grid setpoint and I would like this feature to be built in.

Suggested Solution

Alternatives

No response

Additional Context

No response

Unexpected settings from dynamic-ess

As a picture tells more than words. One would expect the grid setpoint to be set to 0 and battery idle to false when the proposal is 'from battery' as you can see at 1 o'clock.

[Bug]: DESS cannot connect to VRM, cannot create feasible schedule

Contact Details

[email protected]

VRM / Site iD

345657

Country / region

Netherlands (nl)

B max

12

TB max

4

FB max

5

TG max

15

FG max

15

Battery costs

0.025

Buy price

(p+0.02+0.13)*1.21

Sell price

(p+0.02+0.13)*1.21

feed-in possible

yes

feed-in possible

yes

What happened?

The DESS node shows Could not create a feasible schedule. The token is right and so is the site ID.
The strange part is that another site, at another location, with the same token, but a different site ID, works well when I change the site ID in the DESS node. Note, that is on one and the same Cerbo (which is located at 'Thuis")
The site works well in VRM and GX.

The Debug node says: 503 Service unavailable.
And these:
5-9-2023 09:40:06node: debug 1
msg.payload : string[69]
"Unable to connect to VRM for more than an hour, disabling dynamic ESS"
5-9-2023 09:40:06node: Battery control
function : (error)
"TypeError: Cannot read property 'idle_b' of undefined"
5-9-2023 09:40:06node: Payload to graph
function : (error)
"TypeError: Cannot read property 'C' of undefined"
5-9-2023 09:40:06node: Control Outputs
function : (error)
"TypeError: Cannot read property 'gsmm' of undefined"
5-9-2023 09:40:06node: Parse buy price info
function : (error)
"TypeError: Cannot read property 'p_b' of undefined"
5-9-2023 09:40:06node: d113883229f42347
msg : error
"Error: Data: false was not of type number"

ESS Thuis does not work, Red Upsell Zaak works well on the "ESS Thuis" Cerbo GX

Relevant log output

No response

Screenshots

No response

According planning battery should be charged. But instead "idle"

Contact Details

[email protected]

VRM / Site iD

287956

Country / region

Netherlands (nl)

B max

40

TB max

6

FB max

6

TG max

10

FG max

10

Battery costs

0.04

Buy price

(p+0.02+0.13)*1.21

Sell price

(p-0.02)*1.21

feed-in possible

yes

feed-in possible

no

What happened?

I can see in the Node Red dashboard that the system expects to charge the battery from 6pm. But instead it sets the battery to idle.
This way nothing can be charged.

Relevant log output

No response

Screenshots

![DESCRIPTION](LINK.png)

Node Red Dashboard UI not working

Everything is activated as described, the battery is recognized in node red but on the UI all is blank. No graphs etc. What am I doing wrong?

ESS not start charging

Ok, other issue :-) Why isnt the ESS starting to charge? The graphs predict (I guess?) a scheduled charging but when the hour has come nothing happens and is shifts to next hour. Scheduled charging is now for 3 hours already on 10 mins and 10% SOC. Why is this happening?

Strange plan for battery charging

Contact Details

[email protected]

VRM / Site iD

210204

Country / region

Czech Republic (cz)

B max

20

TB max

8.5

FB max

8.5

TG max

9.9

FG max

12

Battery costs

0.04

Buy price

(p+0.150675)*1.21

Sell price

(p-0.0276)*1.21

feed-in possible

yes

feed-in possible

yes

What happened?

Cheep sell price, PV Yield expected, but battery charging only at one hour and only to half capacity to be discharged completly in the evening. This setting is fro 0.04 battery price. It would seem partially correct to charge at highest price, but comparing selling price during the day, it doe not make sense not to charge battery to full, or to at least 85% or so.

If I change battery price from 0.04 to 0.05, no charging at all.

Battery is already at 35% SOC as result from previous day running algo. Yesterday there was real PV yield 25% of expected (heavy rain), but algo still didn't do any recaluclation.

Today I have even switched from Optimized for BatteryLife to Optimized without battery life as previous mode doe not work with algo and on contrary leads to cycling battery at minimu active SOC

Changing to battery cost 0.03 leads to battery charging:

but dischargin is always the same - so even in case that selling is somehow calculated as more profitable than charging, ie charging is expensive, it does not make sense to discharge batery to min SOC in that case.
Or not charging to higher SOC before discharging.

Relevant log output

No response

Screenshots

[Bug]: When calculation is not done (Could not create a feasible schedule), grid setpoint is not reverted to 0

Contact Details

[email protected]

VRM / Site iD

210204

Country / region

Czech Republic (cz)

B max

20

TB max

8.5

FB max

8.5

TG max

9.9

FG max

12

Battery costs

0.06

Buy price

(p+0.150675)*1.21

Sell price

(p-0.0276)*1.21

feed-in possible

yes

feed-in possible

yes

What happened?

During today's testing now I get message Could not create a feasible schedule. I suppose its because of calculation was not successful. But grid setpoint was left at -9900 so batery started to cycle: Discharge into grid to 45% (Life optimized settings), charged to 50%, discharged to 45% etc. Discharge energy was max configured in node.
I had to setup gridpoint manually to 0 in remote console.

Relevant log output

No response

Screenshots

Feature Request: control Relay2 not only by the price but by current/expected PV Yield

Is it possible to modify switch for Relay (2 preferably) to close and open not only based on negative price or below average price, but according to current energy balance?
If there is enough excess energy for heatpump or other usage.
Maybe in config node setup how much energy is needed for devices, controled by relay.
If there is enough excess for past 10 minutes for example and there is expected excess predicted, close relay. If excess drops and stays dropped for like 10 or less minutes and no better prediction, open relay.
I have never worked in NodeRED - started with dynamicESS last week. But i have tried to do it simply for my heatpump by using counter. (counter decrease is faster then increase on purpose). But it can be done better - maybe batch of last 10 minutes data + PV Yield estimation for example?
Adding my example which is active on my site - working with Buderus (IVT) heatpump. Consumption set to 3100 watts (hard number in one function) - relay 2 is connected to External input on heatpump. External input is configured as PV system on heatpump. When relay2 is closed, water comfort level is increased, temperature is also increased by 2 degrees for the next working point in heatpump queue.

relay2.zip

The given name for the accesstoken is not unique

After creating a valid Bearer token, I get an "error" on "Create an access token for a user" when using the generated Bearer token and user idUser.

I'm 100% sure that I use the complete (long) generated token, and idUser.

{
  "success": false,
  "error_code": "validation_error",
  "errors": {
    "name": "The given name for the accesstoken is not unique"
  }
}

Any help appreciated.

Create Victron config client

Customer is complaining he can not get the flow to work because of an error at node Victron-idle-battery. He's using 123SmartBMS.
Is it tied to only VE BMS?

PV yield flat line

Hope nobody thinks I'm annoying :-) , new to Node Red and automating the ESS...

On what is the PV yield based? There is no explaination in the "about". I have AC coupled inverters (which are also enabled in the Console) but my PV line in the dashboard is still flat... Is that only enabled and working for DC coupled PV? From what I tried to understand about it is that the algo will keep in mind that the batteries can be charged with excessive solarpower. I have a gridmeter connected to my Victrons to monitor the feed in to the grid

Other graphs disappear after activating Dyn ESS

When I activate the Dynamic ESS flow, other graphs in the Node Red dashboard disappear. And reverse: after disabling the Dyn ESS, the graphs appear again. What does the Dyn Ess flow do that other graphs disappear?

[Feature]: Dynamic input variables

Contact Details

[email protected]

Description

As it is now the parameters for To Grid, From Grid, To Battery, From Battery etc is configured as static values in the configuration of the node. If these values could be configured by sending messages to the input of the node, it would be really easy to adjust to different installations and needs and also easy solve some of the other feature requests.

Look at the "Power Saver" node and the "dynamic config":
https://powersaver.no/nodes/ps-strategy-lowest-price.html#description

Suggested Solution

Make the node accept incoming messages to control the node's config parameters dynamically.

Alternatives

No response

Additional Context

No response

[Bug]: DynESS graph with error in positive negative axis

Contact Details

[email protected]

VRM / Site iD

287956

Country / region

Netherlands (nl)

B max

not relevant

TB max

not relevant

FB max

not relevant

TG max

not relevant

FG max

not relevant

Battery costs

not relevant

Buy price

not relevant

Sell price

not relevant

feed-in possible

None

feed-in possible

None

What happened?

One graph on the NodeRed Dashboard has switched positive negative display, or explanatory text is wrong.

Text says "positive values represent the energy pushed to the item". In the example you can see that on 2pm the battery is being charged (due to low prices), however this is represented as a negative value in the graph. This is contradicting the explanatory text.

Relevant log output

No response

Screenshots

Feature request: Target amperage in via dynamic ess instead of max power point

Thank you for allowing users to start testing the new dynamic-ess feature.
Currently the node asks you to specify the max feedin/comsume (setpoints) in watts.
However, since the grid voltage can variate over the day I believe it would be better for users to be able to set a max amperage to target.
So that the charging amperage does not exceed the preferred amperage tolerance.
For example a desired amperage of 25A could mean 210 * 25 = 5250watt while 253 * 25 = 6325 watt.
This is more than a kwh difference that cannot safely be accomodated for by having to set a max wattage instead of amperage.
By targeting amperage it would allow the system to maximise the savings (while accounting for grid voltage) provided by this new (soon to be venus) feature.

Remove longitude and latitude

They are taken from the location that has been set in VRM, so no need to put these in the request.

[Bug]: The logic of the algorithm will charge the batteries at maximum load to target without a) taking into account the solar forecast and thus taper the charging and b) once fully charged, with plenty of PV power coming in, throttle down the MPPT chargers and instead take power from the grid at a positive cost.

Contact Details

[email protected]

VRM / Site iD

263771

Country / region

Netherlands (nl)

B max

86.4

TB max

24 (is actually 28.8 but I tried to throttle it down for efficiency)

FB max

24 (is actually 31 but tried to throttle it down for efficiency)

TG max

43.47

FG max

43.47

Battery costs

.05

Buy price

(p+.0175+.12175)*1.21 (ANWB pricing in NL)

Sell price

(p+.0175+.12175)*1.21/1.1 (I use the division by 1.1 to account for the additional inefficiency in the system when operating D-ESS at max charge and discharge)

feed-in possible

yes

feed-in possible

yes

What happened?

A bug is strong wording but the algorithm did not achieve its stated aim in this event on the 16th of July 2023.
Knowing I wanted the system to arbitrage prices I invested in a large inverter setup compared to the battery.
ie. systems that are charge/discharge constraint within the price windows will likely not show this outcome.
Nevertheless it would be great to see the algo working for systems that seek to arbitrage for most of their capacity bandwidth.

Note for the screen shot: With the PV inverter (on AC out) at 819w I would expect the PV Charger capacity to be double that.
The grab was taken at 16.51pm when the battery had been filled since 14.25pm. Given the Solar forecast was reasonable all afternoon I did not expect the algorithm to switch off/partially down throttle (both states were observed on the day) the MPPTs.
Free solar is always better than paying energy tax on slightly negative prices.

Hope this helps and thanks for the great work!

Relevant log output

No response

Screenshots

https://drive.google.com/file/d/1VOY96JHY-uOX2Ls8Nbm_dzfuqYah5rB3/view?usp=drive_linkI