question

When say firmware 2.65 - you mean VenusOS version right? Try to upgrade to 2.9.

And what firmware you are running on the multiplus?

I have a simular setup as you, and I had to upgrade both multipluses and cerbo gx to make everything work.

Yes I am using ESS, but I chose to use mode 3, because of the following limitations for moe1 & 2:

- it is not possible limit charging for a certain max SoC
- mode 1 & 2 do not have the safety-feature to automatically switch to passthrough if you do not update the values within 60 seconds. So if your script dies/crashes, the multiplus will drain your battery.

I have also given up on Modbus-TCP. I tried to ask abour register 2704 here (https://community.victronenergy.com/questions/168029/mqttdbus-mapping-for-maxchargepower-and-maxdischar.html?childToView=168686#answer-168686), but got no response. I think the Modbus-TCP implementation is buggy. It is not possible to write negative -1 for a uint16 type.

What you have to understand is this architecture: https://github.com/victronenergy/venus/wiki/dbus-api

The Modbus-TCP is just a "bridge" between Modbus-TCP protocol and the internal "dbus". So what you want really want is to manipulate (e.g. write) values to the dbus. I recommend using the MQTT bridge insteaf of Modbus-TCP, because the MQTT bridge is a better implementation.

You see, the MQTT-bridge does not need to map dbus-parameters to special register-numbers and provide a Excel-file to explain the mapping (like Modbus). Instead, the MQTT-bridge basically reads ALL dbus values and mappes those 1:1 to a MQTT-topic. This way, you really get to see everything.

Have you tried changing the value directly on the dbus? Login with SSH and use the command "dbus-spy" and find the value you want to change using the arrow-buttons.

Hope this helps.

@sebdehne, thanks for you answer.

I have tried it via dbus-spy as suggested. I have found the values there:

Settings/CGwacs/MaxChargePercentage
Settings/CGwacs/MaxChargerPower

If I modify this values via dbus-spy, the new values are accepted, but no change of the system behavior concerning charging is noticeable.

So this seems to be a general problem, not only related to modbus.

How can I get in contact with a victron stuff or get an answer from victron here?

Best regards

Michael

With DVCC enabled only the modbus register 2705 can be used to limit the system overall charge current. But from my understandig so far it is not possible to disable the charger in the multi directly. This is very suspect to me.

However, my current solution for charging the battery solely with available DC power from the MPPT is:

• Reading the battery current (modbus register 772) from the solar charger (MPPT)
• Using the read current as DVCC system max charge current (modbus register 2705). Scaling needs to be done

This worked for me with DC feed-in enabled. If DC feed-in is disabled, the value set as "DVCC system max charge current" needs to be probably set a bit larger than the "battery current" to prevent the MPPT from throttling down.

Hi all,

This was looked into today. With the introduction of DVCC, quite a while ago, register 2701, and 2072, have been deprecated in favour of new registers. At least for those systems that used that new DVCC feature.

Which was perhaps mentioned in the change log of Venus OS back then, but not in the ESS mode 2 and 3 documentation. Fixed now:

https://www.victronenergy.com/live/ess:ess_mode_2_and_3

My apologies for this!

Matthijs

ps. if indeed this fixes/explains your issue, please accept this answer: it will help other people running into the same problem. Thanks!

@mvader (Victron Energy) Thanks for the information. The update of the documentation helps.

But is there any possibility to disable / enable the charger of the multiplus directly via modbus with DVCC enabled (not affecting the MPPTs)? This would be quite helpful for people that have additional AC coupled inverters and try to manage the charging strategy of the battery (charge with AC power only if DC power is not sufficient to charge the battery over the day, based on solar forecast).

Best regards

Michael

Re the comment on viewing older versions of the manual docs - that's a great example of unusable manual protocol. Instead of industry-standard version labeling and a 'change log' past versions are under an icon! And what about the spreadsheet and doc being out of sync? End result of poorly organised manuals - an endless stream of questions on here which could be dealt with by user-friendly documentation.