Did you tried to ENABLE the DVCC and set its parameters accordingly, to see how it’s behaving?
Some of the execution paths in the DVCC scripts still consider values from the system, even if DVCC is disabled.
For example, the picture where you show the DVCC is disabled, also should have a line with “Controlling BMS”
That line activates if the system found a “valid” BMS in the system.
You are saying you are using a virtual BMS. Somehow this doesn’t show, so the system considers it a non valid BMS.
Why I am saying this?..
Because I want to eliminate that “double master” situation on your system or, at least, the GX to broadcast the same voltage like the controller #36…
Who knows, maybe the 3.18 is more sensitive to this and considers the GX value being the main one, that takes precedence, and therefore 0W production, when the published voltage value is 0V, like it is now…
When the DVCC is enabled, then the GX is forced to send a valid charging voltage, not 0V.
Enabling DVCC results in the same effect that occurs from V3.15 onwards: none of the controllers have any charging capacity left.
I had already suspected that there must be a difference between a virtual BMS and a virtual battery. For this reason, I asked the author of the MQTT driver whether his driver could also emulate a virtual BMS.
As far as I understood him, he says there is no difference.
From what I’ve read, the VE-Bus system also needs to be reset following changes to the DVCC. As I’ve always managed this without resetting the Multis so far, that could be a possible solution. On my 3-phase system, I only have an ESS Assistant and a battery monitor running. The question is: which processes or assistants do I need to run on the Multi for the DVCC to work?
I’ve already read through the DVCC documentation, but haven’t found any clues as to a misconfiguration.
Today I spoke to my other colleague, who has also built a Victron system. He told me that there is generally a bug with the DVCC: if the DVCC is switched on, surplus feed-in must not be active. I don’t quite understand how that works yet, but I’ll test it. He implemented the feed-in using the grid setpoint specification of the Multis with the help of Node-RED.
I’d say that leaves something to be wished for!
As I also read out the data from the solar controllers elsewhere using Node-RED to save it, I am a bit surprised by the voltage value of ‘0’. There, it returns the correct voltage values.
OK, I can switch on DVCC for a test, but as my colleague said, I’ll then have to switch off the DC over-feed. After all, the system is supposed to work as it has done up to now. When do you think you’ll get a reply from Victron?
Hi @Alex Pescaru,
I’ve finished my tests and have come to the conclusion that, unfortunately, with these firmware versions and the DVCC behaviour, there’s no way to run my system on versions newer than 3.13 without altering the system’s behaviour.
Firmware 3.13 appears to ignore a CAN packet that is taken into account in the newer versions, which is populated with data by the GX when a BMS is connected to the system. However, for this to work, DVCC must be switched on and the BMS selected, which in turn means that my ESS Assistant does not charge or discharge my battery when solar power is available (during the day) or when there is no solar power at night, but instead draws energy from the grid or feeds it into the grid.
The behaviour my system has exhibited for a year now – whereby, when solar power is available, self-consumption is deducted first, then the battery is charged, and finally energy is fed into the grid; or, at night, the system is powered entirely by the battery as long as it is above MinSOC – I have been unable to achieve with any of the DVCC variants.
Incidentally, I found it interesting that the Multiplus triggers a low-battery alarm when it receives a battery voltage of 0V via DVCC.
To my mind, this is rather odd, because if there is a BMS in the system, it should also be responsible for the battery alarms. Especially since the Multiplus itself can see the battery voltage and only learns of the 0V ‘by hearsay’.
The change in the firmware of the solar controllers, which absolutely require the battery voltage, is equivalent to permanently enabling DVCC with shared voltage measurement.
Hi @Alex Pescaru,
I’ve actually found a way to get a newer version of the solar controller working for me. You gave me the idea, as you’d discovered that a BMS packet on the CAN bus might be the cause. So I selected a CAN profile without BMS, and now version 3.18 is running without any issues.
It’s likely that the voltage value isn’t being sent to the bus at all. This might also be of interest to you, @BecauseRV. The only issue is the controller’s network status.
Thank you!
No tool… just my eyes and a simple text viewer…
After a while in certain areas of activity, you develop an “eye” for patterns and possible issues.
That packet disappeared since you switched to Lynx…
For now strange thing…
The master controller (36) is broadcasting 58.4V
And Cerbo now is broadcasting 60.4V (!!!), not 0V like before…
Do you have such voltage set somewhere?
So, it seems clear that the controllers with 3.18 consider the Cerbo the main source for voltage information, not the master controller.
And of course is working, because there is no more a 0V value set in the system…
In any case, the batteries are only charged up to around 56.4V. At that point, all the integrated battery management systems switch off and the SmartChunts then show 100%.
Incidentally, I’ve come across another possible cause for the ESS Assistant’s strange behaviour.
The MQTT service was missing information on remaining runtime and ampere-hours consumed. I’ve now added this. So nothing stands in the way of a test with DVCC!
It’s just a shame that such fundamental changes to Victron’s system design aren’t described or publicised anywhere, and that you have to figure things out yourself through trial and error via ‘reengineering’. Even if you create a ‘defect’ report in the forum, you don’t get a useful answer.
