Phasing out the Node-RED Dynamic ESS implementation

Node-RED
, ,
63

That’s because it has been removed from the drop-down list, you’ll only see it if you had it selected already on a previous version before v3.70~47. Yet another one of those things,…

You might be able to use that option by importing this node with that option (pre)selected:

[
    {
        "id": "1e2e5145381aa5ea",
        "type": "vrm-api",
        "z": "4dc207279e9d07bd",
        "g": "f58972a128a5c54d",
        "vrm": "cb2c784a33130f48",
        "name": "",
        "api_type": "installations",
        "idUser": "",
        "users": "",
        "idSite": "{{flow.siteId}}",
        "installations": "stats",
        "attribute": "dynamic_ess",
        "stats_interval": "hours",
        "show_instance": false,
        "stats_start": "bod",
        "stats_end": "172800",
        "use_utc": false,
        "gps_start": "",
        "gps_end": "",
        "widgets": "",
        "instance": "",
        "store_in_global_context": true,
        "verbose": false,
        "x": 500,
        "y": 1200,
        "wires": [
            [
                "f1ba3e65fc57ffa0",
                "b11d18c2ee8828de",
                "7ca6680da5ea01b6",
                "57b54ff352d76459",
                "469c754487107fcb"
            ]
        ]
    },
    {
        "id": "cb2c784a33130f48",
        "type": "config-vrm-api",
        "name": "VRM"
    }
]
64

Even more strange then, as this use case was already to get the Dynamic ESS stats to convert data to get the schedule data back in the DESS monitor page…

65

There is very little ‘normal’ in what took place with this update I’m afraid.

IMG_2025-10-21-16-05-46-579
IMG_2025-10-21-16-05-46-5791920×2560 630 KB

But at least there is a known to be working workaround now by means of above query function node. Use that to adjust the required settings and save the schedule object to the global context from where you can access all the individual arrays (with your own function nodes) for further processing. Such as, but not limited to, extracting the current (time slot) prices.

66

Thanks Jan,

I indeed found another instance of the vrm-api in one of my flows (actually your flow that I adjusted a but to work with the vrma-api node) that still had the Dynamic ESS request, and was able to copy that.

Weird practive indeed. I tried to figure out in the vrm-api source code how it was possible that it is ‘hidden’ in e fresh instance, but no luck….

1 Like
67

Another “funny” thing is when you set Dynamic ESS mode to mode 4 (node-red), VRM DESS will stop calculating schedules and stop fetching prices. So within 24 hours you have no schedules nor prices :distorted_face:

In mode 1(auto), I am not sure yet how much the local node-red schedules will conflict with the schedules set by VRM DESS.

@dfaber are my findings correct and if yes, can you shed some light on the idea from the OP:

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.

68

Yes, it looks like that. Which clearly isn’t as it is supposed to be and will be fixed.
Other findings are also valid, so a new release of the victron-vrm-api node will come out soon, fixing these things.

While that isn’t out yet, the work-a-round is to switch to mode 1 at 23:59 for 15 minutes and then switch back to mode 4.

[{"id":"ae703a43ca8c39aa","type":"inject","z":"9b318a5851e2a91e","g":"848f13b012f3e09a","name":"VRM mode (1) - First 15 minutes of the day","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"59 23 * * *","once":false,"onceDelay":0.1,"topic":"","payload":"1","payloadType":"num","x":270,"y":1100,"wires":[["28afd76d5ed90dde"]],"info":"In order to get the graphics with the pricing to show on\nVRM, Dynamic ESS needs to run in VRM mode. If we just do\nthat during the first 15 minutes of the day, the graphs\nfor the whole day will appear. "},{"id":"28afd76d5ed90dde","type":"trigger","z":"9b318a5851e2a91e","g":"848f13b012f3e09a","name":"","op1":"1","op2":"4","op1type":"num","op2type":"num","duration":"15","extend":false,"overrideDelay":false,"units":"min","reset":"","bytopic":"all","topic":"topic","outputs":1,"x":570,"y":1100,"wires":[["a6b5b452ff171afb"]]},{"id":"a6b5b452ff171afb","type":"victron-output-custom","z":"9b318a5851e2a91e","g":"848f13b012f3e09a","service":"com.victronenergy.settings","path":"/Settings/DynamicEss/Mode","serviceObj":{"service":"com.victronenergy.settings","name":"com.victronenergy.settings"},"pathObj":{"path":"/Settings/DynamicEss/Mode","name":"/Settings/DynamicEss/Mode","type":"number","value":0},"name":"","onlyChanges":false,"x":630,"y":960,"wires":[]}]
69

@snowwie
Did some background checking. While the graphs of Dynamic ESS stop right now (when in mode 4), the scheduling does continue.

The logging shows a few 401’s for your site. That could mean that your VRM api token has expired and would explain you not getting new schedules. Can you check that?

70

@dfaber

Thank you for the workaround and the reply in general. The workaround is what I’ve been doing for the past few days around 13:30 when they day-ahead prices get published. As soon as they show up in the VRM gui, they will be returned by the API as well. (Same for the SOC forecast.)

I am unsure what apicalls throw 401 errors from my node-red flows though, I think I can only spot 200’s. Can you see what is being retreived? (and maybe at what time?)

71

@dfaber do you have any updates on this?

I’m struggling with the same issue. I fetch prices from the API to calculate my own schedule, but they don’t update when in mode 4. A workaround is temporarily switching to mode 1 between 13:00 and 14:00 until they update, but this isn’t a great solution.

72

No, I am sorry, but don’t have direct access to those log files. This is what I got told from the colleague that looked into it.

73

We are going to implement a way to keep the scheduling and graphs going while running in mode 4, but can’t give you a time-frame on when that will be finished.

Until then I cannot offer more than the already given work-a-round.

1 Like
74

Why not make the jump to what seems to be inevitable soon anyway, and refactor the scheduling code out of the VRM cloud into VenusOS? Be done with those modes and multiple layers of schedules trying to keep up with each other, make it one master scheduler running locally, while keeping the data storage and forecasting in the cloud. So much cleaner from a systems engineering perspective IMHO.

75

Jan, such a move would require a firmware update with each and every change/improvement. As it is right now , changes are easier to implement in the backend.

Also. I think that only the Ekrano GX is powerful enough to get that extra workload done, without hampering the performance of what’s already running on the GX devices.

/my 2 cent

76

there is no reason for that, there are many, many ways to isolate a particular piece of process code from the rest of venusOS, Node-RED being the obvious example. I am not saying the core DESS scheduling process should be implemented in Node-RED, I am saying that it won’t be long before some of the community members will be running their own core DESS scheduling process code somewhere else . I prefer Node-RED but it cana be another local machine with HA or even a dedicated ‘container’ on the Cerbo, non of that matters much. What does matter is that there is a lot of interest in regaining control over the scheduler (which is in and by itself an indication that the changes/improvements provided by Victron are not satisfying the requirements for certain use cases)

77

For the past few weeks or so I learned to stop worrying and love the DESS.

While my most requested DESS feature would still be taking system efficiency into account, I no longer need to use node-red to have a healty balance between 0-energy from grid and selling back to grid.

(I used node-red to force my trade-mode system in green-mode schedules when no charge or discharge was planned and kept 25% charge as spare for the night.)

Turns out you can “trick” DESS into calculating this for you way more (cost) efficiently.

  1. Calculate your system efficiency for max DESS-power charging but “normal use” discharging and set it using node-red. (here 89% but default is 90%)
  2. Calculate the system efficiency for max DESS-power charging and discharging (here ~79%)
  3. Multiply your sell price with this difference (here 10%, so *0.9)
  4. Do not set your battery cost too high. My reasoning is the 6000 LiFePo cycles will not be reached before they die of old age so use them as much as possible. (I set it to 0,01)

This way DESS will buy cheap from grid to cover your expected consumption when the price is high or sell when it is really profitable.

afbeelding
afbeelding1702×1809 368 KB

(I just changed the 4ct * tax difference into a 10% difference so the cost graph was adjusted.)

#profit.

I only use node-red for the 15minute graphs now since VRM is not detailed enough. (And uploading stats to pvoutput.org)

2 Likes
78

Although I would generally discourage the use of ‘tricks’, I do find this workaround quite interesting because it adresses a physical ‘reality’ in a transparant way. Thanks.