Emulation dvcc

Modifications
,
1

I have a Victron SmartShunt and a Victron MPPT RS 450/100.
I take voltage and current data using SmartShunt and transfer them via the ve.can bus to the MPPT RS using my own program.

I transfer the following data:

  1. 0x2015 VE_REG_LINK_CHARGE_CURRENT_LIMIT - maximum allowed charge current
    fo example, candump this packet:
    can0 1CEF400A [8] 66 99 15 20 88 13 00 00

  2. 0x2001 VE_REG_LINK_VSET - maximum charge voltage

  3. 0x2002 VE_REG_LINK_VSENSE - current battery voltage

  4. 0x200A VE_REG_LINK_BATTERY_CURRENT - battery current

  5. 0x0FFF VE_REG_SOC - battery SOC

But MPPTRS does not respond to this data, but measures it with its own sensors.
It is necessary for the MPPTRS to react to the voltages that the shunt measures and that I transmit to it on the ve.can bus.
What am I doing wrong?

2

Why don’t you just create a virtual battery and enable DVCC?

3

I don’t have a Cerbo GX device.
I only have a SmartShunt, MPPTRS, Epever Inverter and my monitoring program for these devices.
Therefore, it is necessary to somehow implement sending the correct commands to the VE.CAN bus.

4

Ok. What are you using as the intermediary betwen all the components?

5

I didn’t quite understand the question.
These three devices are monitored by my own program dSolar.
A SmartShunt via ve.direct is connected to it,
an Epever inverter via usb to rs485 via modbus connected to it,
and mpptrs via usb to canbus connected to it.

6

You need to have a “master” in the system that is sending the info and declare a “networked operation”.
Your program is the master.
So, besides those info you need to send the networked mode.
Send periodically (less than 60s) to 0x200E, VE_REG_LINK_NETWORK_MODE, a broadcast message with the current mode.
Usually the value is 0x0D, which means:
bit 0: Operated in network environment
bit 2: Remote Hub-1 control (MPPT will accept charge voltage and max charge current)
bit 3: Remote BMS control (MPPT enter BMS mode)
1CEFFFXX [8] 66 99 0E 20 0D 00 00 00

2 Likes
7

Super nice, by the way !!!
:+1:

2 Likes
8

I send can0 1CEFFF0A [8] 66 99 0E 20 0D 00 00 00 every 30 seconds.
I waited five minutes - nothing changed in the behavior of the mpptrs.
As it was in the idle state - it remains so.
To declare device 0A as a master, is it also necessary to do this with some command?

9

Try to also send 1CEFFF0A [8] 66 99 1C 20 00 00 00 00

1 Like
10

Now there are changes.
MPPTRS gives error #67 - (BMS Connection Lost)
It seems that the mpptrs command
0x200E, VE_REG_LINK_NETWORK_MODE
was accepted.
But I am not transmitting bms data.
I heard that 11-bit identifiers need to be transmitted to the ve.can.
I tried transmitting canid packets:
0x305 - CVL CCL DCL limits
0x306 - dms is active - all byte is 0
0x307 - soc soh
0x351 - current voltage, current, temperature
But the error does not disappear.

11

can0 is a CAN2.0B network, so mostly 29 bit identifiers, 0x3XX BMS data is not present here.

Put bit3 from the 0x200E on 0, because bit3 is BMS control - see previous message.
In other words, try to send to 0x200E ← 0x05
1CEFFFXX [8] 66 99 0E 20 05 00 00 00

1 Like
12

try to send to 0x200E ← 0x05

It worked.
I managed to limit the MPPTRS charge current to 1 ampere using 0x2015.
But there is a problem. When the smartshunt shows a discharge, the MPPTRS does not raise the solar generation to a charge current of 1 ampere.
It seems that the MPPTRS still does not see the current values ​​from the smartshunt (0x200a), or sees it but does not react.

13

Here also the voltage is taken into account…
If the sent target voltage (0x2001) is reached, the current will drop to 0.
The current (0x2015) is only an upper limit.

14

Everything is normal with voltage. Limit(0x2001) - 55.2, now(0x2002) - 53.8

15

By the way, the behavior is similar to the VenusOS.
I installed the VenusOS on the Raspberry Pi for experiments.
Connected the MPPTRS and smartshunt.
Configured the DVCC on it.
Set the maximum charge current to 1 ampere.
I turn on the boiler.
The smartshunt shows the discharge, but the MPPTRS still does not raise the solar generation to the charge current of 1 ampere.
It seems that some data is not being collected for the MPPTRS.

16

Did you tried with bigger currents than 1A? Is the same?
Did you waited for the voltage to drop some? My observation during time was that they are pretty slow to adjust to the new conditions…

17

Yes. Tried with 9 amps. Waited a long time - more than 5 minutes.

18

and what does it mean

0x2013 VE_REG_LINK_TOTAL_CHARGE_CURRENT
maybe this package should be sent to mpptrs instead
0x2015 VE_REG_LINK_CHARGE_CURRENT_LIMIT

?

19

Don’t know about 0x2013… But you can try it.
Be careful, that it’s a signed 32bit value, with 0.001 resolution.

My Cerbo broadcasts only: 0x0FFF, 0x2001, 0x200E and 0x201C
Also, is having a direct - P2P - dialog with MultiRS and is asking for 0x2027 and sends info on: 0x2015 and 0x2017.

BTW…

Nice idea to implement something that behaves like a Cerbo… :+1:
At some point I’ve also though of trying something similar with an ATSAME70, but other things took precedence.
But the idea is still there and you’ve made me remember of it.

1 Like
20

The problem is not solved !
Failed to control the charging process of MPPT RS.
Summary.

  1. MPPT RS refuses to respond to registers:

0x2002 VE_REG_LINK_VSENSE

0x200A VE_REG_LINK_BATTERY_CURRENT

0x2001 VE_REG_LINK_VSET

  1. Responds to a only register

0x2015 VE_REG_LINK_CHARGE_CURRENT_LIMIT

but limits based on the readings of its own sensor and not the SmartShunt sensor.
Therefore, I decided to programmatically calculate the current that must be transmitted to the MPPT RS to achieve the desired current limit on the SmartShunt.

The formula is as follows:
val = CCL - $SmartShunt_BatteryCurrent + MPPTRS_BatteryCurrent

Sincere thanks to @alexpescaru .
Without you I wouldn’t have been able to achieve even such a result.

Sad.
Victron declares openness, but in essence:
“a step to the right, a step to the left - an irrevocable bullet to the head”
A complete description of the ve.can registers is missing.