System unable to charge from generator

DIY
, ,
1

You may want to feed this into them too.
I have just dealt with the fourth instance of generator fails to charge battery bank.
Everything appears normal, generator runs, all connections are sound, fuse are closed etc. Batteries do not charge and VRM (and Smarshunt viewed locally confirms no charging is taking place).

The following appears to resolve the issue:
Using the manual MP rocker mode selector, select charge only. Wait until MP shows AC is charging, and MP is in bulk. Return rocker switch to on / inverter mode.
Issue is resolved and MP charges normally again.

I’m wondering if the change that has affected the display on VRM, has also in fact set the MP shore current limit to 0A? I think the on->charge->on forces the MP to pickup the onboard setting or the correct VRM setting again. Just thinking out loud.

2

Please open a separate topic, just confuses things mixing issues.

3

The problem is there are now at least 4 topics on this very subject, and those posts aren’t being directed back or merged to a single source of information.
e.g: Quatro/Multiplus State/Controls incorrect in VRM

I’ve fed in and tried to help, my job isn’t issue / bug triage on a Friday evening. That’s a role for a dev / helpdesk manager. Receive incoming information, evaluate, consolidate, allocate. I’ve already spent 4 hours fielding the VRM and charging issue this week. I’ll see if I have time on Monday to open yet another fresh topic, related to this topic.

4

I’m almost 100% sure your described problem has nothing to do with the VRM.
Unless you use DESS the VRM portal doesn’t control your system, the VRM portal is for monitoring.

You could test that by disconnecting your GX device from the internet.

5

VRM does in fact control, for example, a MP via the VRM. Commands are issued via the VRM platform to a MP/Quattro and other devices. This is explicitly stated in the VRM manual.

Here is a link to the Victron Energy VRM portal manual (see section 5): 5. Control your devices in VRM

To save you from reading it all, it states:
"VRM offers control over some of your Victron devices, straight from the VRM dashboard. With this feature, you can quickly adjust and control the following devices or settings without needing to open the Remote Console:

ESS settings: ESS mode, Minimum SoC

MultiPlus/Quattro: Grid current limit, Mode (Charger only, Inverter only, On, Off)

GX device relays: Relay 1, Relay 2 (if available)

EV Charging Station: Auto, Manual, Charge current, Charge on/off

Generator: Autostart, Manual control, Timed run, Start/Stop"

Grid current control on the MP/Quattro is specifically specified. As far as I am able to ascertain this is done via MQTT over a reverse tunnel. In much the same way the remote console data is retrieved and set via the ‘Remote Console’ UI from a client browser.

That was the reason for my ‘feed-in’ post.

I still stand by the assertion that a possible errant command was issued to MP/Q devices to limit current to 0A or change mode to ‘Inverter Only’

Why? What supports the assertion / theory:

  • The behaviour is being observed within the same issue window, with the VRM issue relating to loss of display and functionality in the VRM MMP/Quattro control. This explicitly relates to the ability to set shore/grid limiting and mode directly from the VRM.
  • Switching a unit to ‘Charge Only’, and then back to ‘ON’ resolves the issue.
  • Currently there is no evidence of the ‘No Charging’ issue persisting or returning after the resolution action.
  • The issue and resolution are repeatable across multiple unrelated devices.
  • The issue and resolution are repeatable across multiple unrelated installations.
  • The involved devices are running different firmware versions from v3.70 - 3.81

Experienced users of the VRM will be fully aware via practical use, that via the VRM an authorised user can use the MP/Quattro control panel, in VRM, to change the grid / shore current limit, and change switch modes on an installations MP/Quattro.

6

Control means that vrm has authority to make changes. Outside of dess, it does not.

It provides remote access to your system controls, requiring manual intervention on your part.

It cannot do this autonomously.

Even in the dess scenario, it is not explicitly controlling the system, it is creating schedules which the GX receives and actions.

7

YOU can control some devices via the VRM portal but the VRM portal doesn’t control your devices on it’s own.

8

Your statement is demonstrably untrue.

The ability to set a AC input current limit via the VRM control widget has NEVER been dependent on implementastion of DESS.

None of the installations in my fleet and that I have dealt with for others over the past week which have experienced issues, use DESS.

However an installation NOT using DESS, has always been able to use the VRM to remotely change the shore/current limit AND switch mode.

The whole point of the shore current limit is to be able to limit the input current on the AC In channel(s). Even Victron’s documention promotes this functionality for generator and limited grid supplies such as when connected to limited marina shore line supplies. Please see as an example the Victron document: https://www.victronenergy.com/upload/documents/Technical-Information-Achieving-the-impossible-EN.pdf?utm_source=chatgpt.com
Absolutely ZERO requirement for DESS.

This is done by a control mechanism sending the specified current limit as an integer to the /Ac/ActiveIn/CurrentLimit dbus-object-path which is a writeable value.

Active input current limit 22 int16 10 -3276.8 to 3276.7 /Ac/ActiveIn/CurrentLimit yes A

AC input current limiting does not require Dynamic ESS (DESS), or ordinary ESS. It is a standard inverter/charger function using PowerControl and PowerAssist.
Victron’s MultiPlus-II GX manual, section 9: Configuration provides direct evidence:

  • It identifies the section as mainly for stand-alone applications, directing ESS installations to separate documentation.
  • Section 9.1 lists AC input current limit among the standard settings.
  • Section 9.2, under AC input current limit, states:
    “These are the current limit settings for which PowerControl and PowerAssist come into operation.” victronenergy.com

Therefore, a boat with a suitable MultiPlus can use shore current limiting without implementing ESS or DESS. PowerControl reduces charging to accommodate other loads; PowerAssist uses battery energy to supplement the shore supply when needed. Victron describes both as standard features in its MultiPlus manual, section 2.1.

The VRM explicitly has the ability to make changes, via data issued to the CerboGX, to write new values to the dbus registers which are pushed/read in turn to/by the MP. The MQTT broker on the CerboGX takes these MQTT commands and writes the new value to the dbus.

So if you want to define ‘autonomously’, which in the case of a programmatic system such as VRM, can be taken to cover a huge swathe of meaning…

But to be simplistic:

The VRM holds / reads an AC Input value as an integer 0-198 (I’m pretty sure this is the upper bound).
If the value is changed in the VRM by a user it would be possible to simply write/push the new value ‘onchange’.
However good programming practice is to ask a user to confirm such an action (“Are you sure”, “Save”, “Update”), it is simply a programmatic step before calling a ‘write/change/update’ type function. However it is wholly possible to call the function without any such confirmation or interaction with a user. Such as when a user types into a document and the document is updated on the ‘keyup’ action, it would be impractical to prompt the user on every occasion.

It is therefore wholly possible that a VRM issue or error could see a value set (even programmatically), and then sent to a device without the calling of the user confirmation prompt.

I’m not saying that is the case. It would also appear you have no evidence that it is not.

9

You’re failing to understand what I wrote.

There is a difference between controls - making remote buttons available via VRM for a user to adjust their system - and control - the ability for VRM to autonomously change settings on your system without your input.

It can only do the former, the latter is something it can indirectly adjust via DESS.

VRM has always offered a web-based way to access remote controls ordinarily done via the remote console. This is dependent on real-time access and the right access being allowed.

It has never been able to switch or adjust any setting by itself.

The current parameters it shows are ones sent to it by the GX, these can only be overridden if a user does so themselves.

There is no scenario where it will just spontaneously change a running setting.

10

Afraid not. It just does not work that way. There is no scenario where a glitch will just push out settings that override the GX. In much the same way, the GX itself cannot just change a setting because of a hiccup. Just not how it is architected. The reports that have (rarely) surfaced have inevitably been a result of system customisations.

11

So thank you for now recognising, your previous post was factually incorrect.
Some devices can be controlled via the VRM without use of DESS, unlike your previous post that stated as an absolute:
“Unless you use DESS the VRM portal doesn’t control your system, the VRM portal is for monitoring.”

If you mean that with DESS that there is a planner/enforcement mechanism (that the VRM plans the use and the CerboGX enforces the actions). The CerboGX receives a schedule from the planner to execute (I think this is a about 12 hour plan). In the event of internet loss the CerboGX will execute the received schedule / plan until that plan is complete, but requires connection back to the internet / VRM to receive the new plan (set of switching instructions). This plan is complicated and the CerboGX was never designed to run an algorithm to produce such a plan. Hence this is off-loaded to the VRM cloud.

However the payload to alter the switch state, as an example, via mqtt, is only:
mosquitto_pub -h <CERBO_IP> -p 1883 \
-t ‘W/<VRM_PORTAL_ID>/vebus/257/Mode’ \
-m ‘{“value”:1}’

Please see my later post regarding the inaccuracy of your DESS assertion.

As for control, also see my subsequent post.

The VRM platform sends the relevant data to the Cerbo GX, the CerboGX does not check to see who or what issued the data payload. AFAIK It only checks that the correct authorisation user/password has been authenticated. It then simply parses the payload and writes values to the correct dbus registers for reading / sending to the relevant device.

Example of non-user control changes would be, but there are multiple others. No FW updates etc reported:

12

I never wrote that it’s impossible to control some devices via VRM.
YOU as the user can control some devices through the VRM.

But the VRM can’t control if your MultiPlus/Quattro accepts your generator or not.
That’s depending on local settings inside the MultiPlus/Quattro.

13

You’re quoting an inconclusive (no outcome nor confirmation or a fix) from old beta testing after upgrading between betas on the GX itself. That in no way supports your conclusion but does support the risks of updates, especially betas. In the many years we have been doing this, if it were a verifiable issue we would have escalated it. There is just nothing that actually supports it, when topics just die it tends to be when the OP has figured out something they forgot.

14

I did understand what you were saying.
I think you are refusing to acknowledge the possibility of an issue.

So to be simplistic:
User changes current limit in VRM control widget from 12A to 16A.
VRM presents confirmation dialogue.
User confirms change
VRM calls ‘update’ function and a payload is transmitted to the CerboGX.
CerboGX reads the payload and amends the stated MQTT topic.

15

The classic prove a negative. What I am highlighting is the nature of the senario is not without precedence.

16

It is not architected like that, you’re trying to create a fictional scenario to support your issue without understanding how it really works. The assertion is pure fiction, you are welcome to believe that, but it is not constructive to the discussion and it is nothing that any of the team is likely to take seriously nor escalate. Sorry, there just is too much to do than argue about this.

If you believe there is an issue, please find a way to reproduce it, then we can have a look.

Until then, this horse has been flogged and it is distracting from the real, recognised, issue of the controls having disappeared from the interface.

17

So as an example. In my senario.

Multiple users report the same issue - MP does not charge from ACIn connected to generator.

Multiple systems, unrelated etc (see my previous).

The fix (see my previous).

So why would multiple unrelated systems, all exhibit the same behaviour, within a short time window (7 days).

Why would all system issues be resolved by the same resolution action?

I have now enabled full packet logging for my own system so any VRM originated data can be logged and payloads examined in future.

I’ve not had to run a shore power / generator connection yet for charging.

18

The missing/inaccessible current setting in VRM did not change that the parameter was still configurable on the GX itself and that the values persisted. It appears to be a rendering issue in the interface, but has no bearing on how the system functions.

The other reports are all about VRM showing information that is not correct for the running system, no one reports that their system is misbehaving, purely that they cannot control it via VRM as they would like to.

There is simply nothing in VRM that could make your multi/quatro decide not to charge.

In your hypothetical scenario, if VRM could send changes, as it is a proxy for the GX, any changes would be visible in GX parameter changes. It would also be visible via the inverter state. There is zero probability that a charger/inverter could inherit any change not reflected by the GX. The soft-switch overrides the physical switch (we have had enough reports of people turning off their system in error and being unable to turn it on again), so changing that typically doesn’t help.

You can easily change VRM access to read-only, that would confirm things fairly quickly.

Bottom line, if you can’t see anything actually set locally that shouldn’t be set then it is a local issue and something has changed.

We can’t diagnose this remotely, so you will need to find more concrete data to define the issue, grasping at VRM just seems to be a distraction.