This page explains how to use a Multi/Quattro as a bidirectional inverter operating parallel to the grid, integrated into a customer designed system (PLC or other). In mode 2, Advanced, or more 3, Custom.
Note that it is also possible to run a Victron grid parallel storage system without designing and implementing your own control loop, logic or measurements. See the Hub-4 manual.
Note that though this page mentions Hub-4, which is deprecated, it also applies to ESS.
The system runs automatically, and uses excess energy harvested during the day to fill the gaps when there is not enough PV power available. Typically in the evening and night. Easy configuration in Assistants and on the Color Control GX. For details refer to the main hub-4 manual.
Same as standard operating mode, but customer adds custom control doing time shifting, load management or other energy management optimization algorithms. The required components in the system, as well as the general software setup, is 100% equal to the default, Mode 1. The available control points are:
There are two ways access those control points:
For more information, see the Mode 2 details.
Customer self implements their control loop and grid measurements, and uses the MultiPlus and/or Quattros as simple, remote controllable, bidirectional inverter/chargers that can be set to either charge or discharge an x amount of Watts. Note that the point of control is the AC-input, not the charger itself.
Power to/from AC-input = Power to/from battery + Power to/from AC-output
Necessary Victron equipment:
Available control points:
For more information, see the Mode 3 details.
Reduces the charge current relative to the maximum charge current. Note that this settings has a higher priority than the Grid power setpoint.
max charge percentage * max charge current * battery voltage / 100
Though presented as a percentage, it is really a on/off mechanism. Setting the percentage below 50% will disable discharge. And setting it equal to or above 50% will enable discharge.
See the Modbus-TCP excel sheet for scaling and datatypes, available here.
See above mentioned register numbers. Use ModbusTCP unitid 100.
Recently we have added MQTT to the protocols on the CCGX. For more information, see the developer mailing list as well as the mqtt github repo.
Start reading here.
The Hub-4 related D-Bus paths are:
In standard mode the Hub-4 control system tries to keep the power flowing through the grid meter at 0 Watt (so no power is taken in from the grid, nor is any power fed back to the grid). Mode 2 means you set the target for the grid power. Setting the target to 100 Watt means that the system tries to take 100 Watt from the grid. The power will be used to feed the loads or charge the battery. Similar, a negative value will instruct the system to feed back power to the grid. This will be PV power when possible, otherwise the battery will be discharged. Reset the setpoint back to 0 Watt, and you are back in standard mode again.
In addition you can also control battery charge and discharge. This allows you to control when the battery is charged and discharged.
Mode 3 means you take direct control of the Multi itself by setting the power it should take/feed back on its AC input. It allows for easy control of the power flowing to the battery. The power flowing to the batter (or more precise: to DC system attached to the Multi) is equal to the AC-In power minus the AC-Out power. In mode 3 you have to create your own control loop, and update set setpoint frequently.
If no new value is sent to the Multi for longer than 500 periods (= 10 seconds at 50 Hz), the Multi will automatically fall back to 'bypass' that is: No charge/No discharge. The internal transfer relay is closed when AC input is available. In that case any loads on the AC output are fed by the AC input. If there is no AC input available, the unit will switch to inverter mode. (Unless it is set to 'Charger Only' or receives a 'low cell' signal from the VE.Bus BMS).
In this setup, it is not necessary to use a CCGX. Instead an MK2 is used. We have both MK2-RS232 and an MK2-USB available, see the pricelist. A direct connection to the VE.Bus RS485, without MK2 or CCGX, is not possible.
Note that, as also indicated on the Datacommunication whitepaper, the MK2 protocol is not an easy protocol. That is unfortunate, but it is what it is. And we cannot give support on it unless there is a huge commercial value behind the project, read thousands of Multis or Quattros.
And now, after all the warnings, the information:
Use RAM ID 128 and higher. Every RAM ID is a word (2 bytes)
The assistant RAM will be filled from ID 128 with ‘assistant RAM records’. Each record starts with a word that contains the AssistantID and the size of the record, and then a number of AssistantRAM words.
RAM ID | contents |
---|---|
128 | ID_Size (1st Assistant) |
129 | 1st AssistantRAM0 |
130 | 1st AssistantRAM1 |
… | … |
RAMn | 1st AssistantRAMn |
RAMn+1 | ID_Size (2nd Assistant in this VE.Bus device, if any) |
RAMn+2 | 2nd AssistantRAM0 |
RAMn+3 | 2nd AssistantRAM1 |
etcetera |
The ID_Size word contains 0xZZZY, where:
So you have to scan the Assistant RAM records by looking at each ID_size record.
Search for HUB4, and then AssistantRAM0 is the setpoint in Watts and AssistantRAM1 contains the flags:
Above information is an addendum to the 'Interfacing with VE.Bus products' document. Available from our whitepapers.
EXAMPLE:
Below you will find a communication example (assumed is that the HUB-4 assistant is the 1st assistant in the assistant list using AssistantRAM. So this means that the ID_Size is at RamID 128.)
Reading the ID_Size:
→ 0x05, 0xFF, 0x57, 0x30, 0x80, 0x00*, 0xF5
(Length, 0xFF, ‘W’, 0x30, Lo(ID), Hi(ID), Checksum)
Response:
← 0x07, 0xFF, 0x57, 0x85, 0x32, 0x00, 0x52, 0x5A, 0x40
(Length, 0xFF, ‘W’, 0x85, Lo(ValueA), Hi(ValueA), Lo(ValueB)*, Hi(ValueB)*, Checksum)
ValueA is the contents of RAMID 128. In this example it is 0x0032 which indicates HUB4 with 2 extra RAMIDs.
*) Please note that you will get an extra ValueB. This is a feature of newer Multi firmware versions. Because the IDs range from 0..255 the Hi(ID) field would always be 0. Newer Multi firmwares allow you to specify a second ID in this field. So in this case ValueB is the value of RAMID 0 because the 0x00 is interpreted as the second ID. RAMID 0 corresponds with UMains (This can be found in paragraph 7.3.11 of the 'Interfacing with VE.Bus products' document.) So in this example the UMains value is 0x5A52 ⇒ 231.22V NOTE: You will always get a ValueB in the response. You can make handy use of this by reading an extra RAMID or you can ignore it if you don’t need it.
Writing the set point with +200 Watt:
We should write RAM ID 129 to +200.
Writing requires 2 frames, one frame specifying the ID to write and one frame specifying the data to write.
→ 0x05, 0xFF, 0x57, 0x32, 0x81, 0x00, 0xF2
(0x32=Command Write RAMID, 81 00 = 129, Note that 2nd byte will always be 0 in this command)
→ 0x05, 0xFF, 0x57, 0x34, 0xC8, 0x00, 0xA9
(0x34=Command Write Data, C8 00 = 200)
Note: If a negative set point is needed you should specify this as the 2’s complement value so for example -200W must be specified as 0xFF38 (=65536-200) so that would result in:
→ 0x05, 0xFF, 0x57, 0x34, 0x38, 0xFF, 0x3A
Response:
← 0x05, 0xFF, 0x57, 0x87, 0x00, 0x00, 0x1E
Write OK (87 means successful. Just ignore the rest of the frame (00,00 in this case))
Please refer to the 'Interfacing with VE.Bus products' document, available from our whitepapers, for more info.
~~DISQUS~~