Battery Monitor Control–can't select service path(Virtual Battery), existing nodes become uneditable

[andrewd (Andrew Doroshenko)]

Hello,

I am experiencing an issue with the Battery Monitor Control node (“blue” node) in Node-RED on a Cerbo GX.

System

• Device: Cerbo GX

• Venus OS: 3.70.

Problem Description

Previously, I used the Battery Monitor Control node to write values into a Virtual Battery device.

My flow architecture was:

1. Read parameters from a real battery

2. Modify values in a function node

3. Send corrected values into a Virtual Battery using Battery Monitor Control node

This setup has been working correctly.

However, now:

It is no longer possible to select any service path in the Battery Monitor Control node.

• The “Battery Monitor” dropdown is empty or shows the device as disconnected.

• I cannot re-select the Virtual Battery device.

• If I disable and re-enable the node, I immediately lose the working configuration.

• I cannot recreate the same node because no paths are available for selection.

The node still works as long as I do not touch it, but it is effectively locked and uneditable.

Error Message

Inside the node editor I get:

“The device is no longer available via the stored service path. Please (re)select the device from the dropdown and deploy again.”

But there are no selectable paths available.

Important Context

The Virtual Battery device still exists and is operational.

The flow is actively updating values such as:

• CCL (Charge Current Limit)

• CVL (Charge Voltage Limit)

The logic chain works:
Real battery → Function nodes → Virtual Battery

Only the configuration interface of Battery Monitor Control is broken.

Reproducibility

If I try to create a new Battery Monitor Control node, I cannot select any battery service path at all.

These are the “blue nodes”, which normally should remain stable and not change unexpectedly between firmware versions.

There is of course a workaround using Custom Control node, but:

• Custom nodes are explicitly marked as not guaranteed to remain stable.

• They are generally not recommended for production logic.

In addition, the same issue is not limited to the blue nodes — it also affects the orange Custom Control nodes, specifically for paths under com.victronenergy.system.

Normally, I would not emphasize this, since I understand that custom nodes are not guaranteed to remain stable across firmware updates. However, the situation here is different: all paths starting with com.victronenergy.system have completely disappeared from the selector.

I rely on these system-level paths for fine tuning and advanced adjustments, so their removal significantly limits functionality within Node-RED.

Any guidance would be appreciated.
This node is critical for custom Virtual Battery control logic.

Thank you.

[dfaber (Dirk-Jan Faber (Victron Energy))]

I am able to reproduce this. Checking on how to fix this. Thanks for reporting.

Update: Doesn’t look like an actual issue, see further answer below.

[dfaber (Dirk-Jan Faber (Victron Energy))]

Ok, this is a bit more detailed than necessary, but here goes my analysis:

It is correct that the battery control node doesn’t work for most batteries - it only works if the underlying battery exposes the /Mode path, which is exclusive to the Lynx BMS. For all other batteries it will show “no paths available”. At some point the node did list read-only paths by mistake, which was likely the version you were running before.

Then on the com.victronenergy.system service. This is an aggregated service which exports read-only paths only. Which is why it is filtered for the custom output control node. I’d be curious to know which paths of the system service you were writing to - my strong suspicion is that even if no error was shown, those writes had no effect whatsoever.

For writing to the virtual battery you can still use the custom control node, or write to multiple paths in one go via the input of the virtual battery node itself. The latter being the supported way.

So as far as I am concerned this is all working as intended, but I realize it’s not helping you much.

But this might help getting your flow back on track again:

This is showing how it is supposed to work (just tested on my system). The battery monitoring nodes read the values from the dbus and store them in the global context. The function node uses the global context to make a msg.payload that writes the paths into the virtual battery. I limited the example to 3 values.

So the function node looks like:

msg.payload = {
  '/Info/MaxChargeVoltage': global.get('victronenergy.battery._512.Info.MaxChargeVoltage'),
  '/Info/MaxChargeCurrent': global.get('victronenergy.battery._512.Info.MaxChargeCurrent'),
  '/Soc': global.get('victronenergy.battery._512.Soc')
}

return msg;

I hope this clarifies how it should work. If not, please let me know.

[andrewd (Andrew Doroshenko)]

Hello.

Thank you very much for the detailed example — it really works. The Virtual Device node itself was changed between firmware 3.67 → 3.70: it now has both an input and an output. It’s also very convenient that several parameters can be updated at once. I really like this functional improvement.

However, for now I have temporarily stopped using the Virtual Battery, because I noticed another serious — even critical — issue. It actually creates more problems than benefits and forced me to find another way to achieve the same goal. At first it was not obvious what was causing the issue.

To reproduce the problem:
for example, you create a Virtual Battery and copy all the main parameters exactly as shown in your example. Everything works perfectly at first. But…

Now, every time you perform a Deploy, if you simultaneously open the VRM dashboard on another device (for example, a phone), you will notice a sharp current spike. In my three-phase MultiPlus-II system it looks like this:
almost full-power export to the grid for a few seconds → then a few seconds of full-power charging → then stabilization, after which everything works normally.

If I then change something else in the code and do another Deploy, I get the same large power spike again: first battery discharge with grid export, then strong charging.

In my case I have a feed-in (“green tariff”) contract, and if the operator sees temporary generation at night — even if it lasts only a few seconds — it does not look good at all. I still don’t know the consequences, since the month has not finished yet and I have not yet received the report from the grid operator.

As a workaround, I found the following sequence:
before doing Deploy, switch the battery back to the original CAN-connected battery, then Deploy, and then switch back again to the Virtual Battery. In this case everything works correctly.

My guess is that the spike may be related to the CVL (Charge Voltage Limit) parameter. Possibly during initialization the ESS control first receives 0 or null, which causes an abrupt battery discharge and grid export. Then, when the system receives the real CVL, it quickly switches to charging, and finally the system stabilizes.

I do not see another explanation, because if I follow this path:

Settings → System Setup → Batteries → Battery Monitor → [My CAN battery]

DEPLOY

and then switch back:

Settings → System Setup → Batteries → Battery Monitor → Virtual Battery

then everything works smoothly with no spike.
But doing this every single time before a Deploy is very inconvenient.

This slightly reduces the problem, but it does not eliminate it completely, even if an initial value is specified.

Now the second point.

If Battery Monitor → Automatic is selected, the system automatically chooses the real CAN battery, not the virtual battery.

If the virtual battery had priority, it would actually make more sense. The main reason to create a virtual battery is usually to achieve a different control behavior, so logically the virtual battery should be selected by default when Automatic mode is used.

In that case, the problem I described above might not occur at all. If the virtual battery has not yet been created during Deploy, the system could simply run on the original battery for a few seconds, and then automatically switch to the virtual one once it becomes available. That would likely avoid the power spike issue.

But this is only a hypothesis regarding the CVL.

Please try to reproduce it on your side — you should be able to observe the spike.

Best regards.

[andrewd (Andrew Doroshenko)]

Now regarding com.victronenergy.system.

Here is one example of how I specifically use writing values to com.victronenergy.system.

[andrewd (Andrew Doroshenko)]

Here is another example.

I reduce SolarVoltageOffset to give priority to AC-coupled grid inverters over the DC charger

[andrewd (Andrew Doroshenko)]

@dfaber

I’d be curious to know which paths of the system service you were writing to - my strong suspicion is that even if no error was shown, those writes had no effect whatsoever.

Both of these examples work. Writing values to com.victronenergy.system produces a real effect. You were interested in seeing which paths I write to, and you can verify it yourself — these paths do affect the system. It’s easy to test using simple Inject nodes.

[dfaber (Dirk-Jan Faber (Victron Energy))]

I will respond later on your other remarks, but first one that might help you a bit. Did you know that, instead of hitting the deploy button, you can also deploy a part of the flow? If you press the triangle on the right side of the button, you get a menu allowing you to deploy only the modified flows or the modified nodes instead of doing a full deploy.

[andrewd (Andrew Doroshenko)]

@dfaber

Did you know that, instead of hitting the deploy button, you can also deploy a part of the flow? If you press the triangle on the right side of the button, you get a menu allowing you to deploy only the modified flows or the modified nodes instead of doing a full deploy.

Thank you. I had always been doing a full deploy and never really thought about the possibility of deploying only the modified flows.

[dfaber (Dirk-Jan Faber (Victron Energy))]

It is easy enough to miss that option. I personally discovered it accidentally when hitting the button on the right side once.

And I learned today that not all paths in the system service are read-only. I’ve adjusted it in the code, which is awaiting review by a colleague. Once that is done I’ll tag a new release and try to get at least that in 3.71.

[andrewd (Andrew Doroshenko)]

When testing the Virtual Battery / Deploy current spike issue I described earlier, it may be necessary that the following option is enabled:

Settings → System Setup → ESS → Grid feed-in → DC-coupled PV – feed in excess → ON

The reason is that when this option is enabled and the CVL (Charge Voltage Limit) is reduced, the system will export power to the grid from the battery (from the DC bus) until the DC voltage drops to the CVL value.

Accordingly, if this value suddenly decreases, it will immediately cause rapid export to the grid, and if it is suddenly increased again, the system will switch to battery charging, especially if the following mode is selected:

Settings → System Setup → ESS → Mode → Keep batteries charged.

[dfaber (Dirk-Jan Faber (Victron Energy))]

If you switch to the beta channels version of Venus you will already get the option back to use the custom control node to adjust the system paths. This is scheduled to go into 3.71, so you can also wait for the new official release.

One sneak-preview for the 3.80 branch though is that I’ll be adding an option to start a virtual device disconnected where you’ll need to send a msg.connected with the value true to get it online (or false to get it offline again). That isn’t in yet, but seems the easiest way for you to first make sure the virtual battery has all values correct before putting it online. I expect to get that in one of our next beta’s.

[dfaber (Dirk-Jan Faber (Victron Energy))]

FYI: On the current beta (3.80~7) the option to start a device in disconnected state has been added.

So you can first fill the values and then send a msg.connected = true to get the device online.