Simplifying system setup

Modifications
1

This has been itching me for long time, from very start when I got my first blue box.

We all - both users and Victron support, seem to spend a lot of time with numeric parameters to match different products (inverters, batteries, solar panels, MPPT’s, shunts etc) to work together. Looking for where that battery PDF and specs were, and then entering those voltages and currents into correct configuration dialogs via various user interfaces.

At the end of the day, all those are public information. This could be simpler, easier, more accurate and lead to safer systems.

How about:

  • defining a XML specification schema for each type of device
  • writing a specfication data file for each device
  • publishing them at Victron server via REST API for machine-to-machine use
  • GX device would push correct settings to each device in its domain

Then users would choose device make and model (even better, autodetected) which would be a lot easier than typing in all the numeric parameters that get lost in every update (why that happens?). There could be an option to deviate from factory settings with user override as there is already in some devices.

Victron could release new format versions and update the device data as new information would become available and when errornous information would be found and corrected.

These format versions and device specs would probably have to be released in bundles that could also be transported via usb-sticks for offline sites, just like firmware updates.

I’ve written XML schemas and it would suit well for this kind of application where different organizations (eventually) release information used by others and where cannot be different interpretations (judged by validation) of the same format.

The format defination would proabably be used across the industry once one company would create and start maintaining it. For example battery manufacturers would publish their specification files along the other documentation, just like they’re already using each others CAN-protocols.

Juha

originally published: https://community.victronenergy.com/questions/269001/simplifying-system-setup.html?

1 Like
2

I believe “Forced DVCC” for managed batteries largely solves what are you describing.
https://www.victronenergy.com/media/pg/CCGX/en/dvcc---distributed-voltage-and-current-control.html

Nowadays I rarely use non-managed batteries, but I guess there can be more presents to choose from in the VEConfigure / VictronConnect software … or this setting could also be present in the GX device for setups with voluntary DVCC enabled. XML repository of such presets could be part of GitHub source code of Venus.

1 Like
3

I have Pylontech battery and I still need to set values for it. And I think the basic values that Pylontech lists in tech specs are different that Victron does at their particular web page. Like you said, DVCC handshakes a lot, so it should do it all.

4

I do have PylonTechs too, and I set the values just in case there is a problem with the CAN communication to be on the safe side. The system usually shuts down when the CAN communication is interrupted. So I believe it is not strictly necessary.

Also, in case of Pylontech, Victron actually overrides some of these values with lower ones they figured work better in this particular case.

1 Like
5

As you can see here

https://www.victronenergy.com/live/battery_compatibility:pylontech_phantom

*Chapter 5. *
Charger and inverter settings in VEConfigure are done manually.

which comes to the fact that why VenusOS can’t talk the VEConfigure protocol and offer those settings in menus, as well do this stuff automatically as I suggested.

Here is also Pylontech specs

image
image821×609 77.3 KB

they don’t list absorbtion and float values. Charge voltages are already over the Victron’s float value.

6

Hi @tuju

I really like the idea, it’s definitely next level thinking.

In a way we are working on the back end infrastructure to manage something like this (via a fully featured VictronConnect that can talk to all Victron devices, combined with a deeply embedded and extended VRM interface).

As @Peter says, in most cases for most managed batteries, the DVCC method does take care of this. There are some edge cases that are smoothed over with manual settings which is why we still advise setting some manually, but they are mostly fallback. If you take a Victron MultiPlus and MPPT and connect them to a GX device and a managed battery on the supported compatibility list, then it will work out of the box.

From there (such as bringing all firmware to current on a new installation) are recommended because it isn’t yet a perfect world.

I agree with you that there is more we can do to help streamline installation, especially for installers who are doing this every day. There are some really exciting and very long awaited features coming along this line, but it’s a bit soon to go into details here.

2 Likes
7

You’re saying that Windows binary VEConfigure is going away? Currently there are:

  • VEConfigure (for inverters)
  • VictronConnect (for anything with BT, not inverters)
  • VenusOS in GX (controls, not configure so much)
  • VRM remote configuration using VE.Configure via VenusOS (whole cfg push)

VenusOS can’t show + change configuration, you even have to disconnect i from VE.bus when using VEConfigure. And you can buy a BT-interface (VE.Bus Smart dongle) for inverters, but still not configure via it. But apparently you can remotely push whole configuration file via VenusOS and VE.bus.

I kind of understand VenusOS vs others split as not all sites have GX-device. But ones that do, the end result is quite overwhelming. Those configuration operations could be separated into libraries and used also via VenusOS at GX-sites, and forget the whole VE.Configure.

I’ve Quattro, it’s basically the MP and it doesn’t do that. Contrary, I need to make a lot of checks and adjustments in MPPT and inverter until all the errors and alarms are gone. All that could be plug-n-play and automatic.

When the industry says everything should be the latest. There is also a split inside Victron ecosystem: inverters should not be upgraded and VenusOS should, you can even set it to do it automatically, beta release if you like.

When the last one is mainly a communication issue, people don’t remember it and user interface don’t advice nor give hints about it.

I would merge VEConfigure and VictronConnect into one, provide the resulting functionality also in VenusOS. And make more automated setup experience using my XML-proposal. Results would not depend on VRM nor its backend at non-internet sites.

8

The RS inverter range does not use veconfigure, it is setup with victron connect.
The legacy systems just don’t have any other way to connect to them apart from vebus, so that forces a mk3 or remote access via the GX.
The VC app works well to configure the majority of settings on multis and quattros, just not assistants.
It has always been the goal to get VC as full featured as possible.

9

That’s probably because it has BT.

Yes. MK3 is VE.bus, modbus-to-USB adapter and GX uses that very same modbus when it’s not being configured. It’s a software limitation.

image
image1125×904 48.6 KB

So I should see Quattro in VC app then? Never seen it there and sure, the Cerbo’s BT is only for Wifi-initialization as we’ve been told and experienced. Quattro doesn’t have BT. Only viable route is VRM (in the pic).

10

The app only works locally for vebus systems when used in conjunction with a mk3.

11

Ah, you mean when using on Windows. Right.

12

I use a mac. Unfortunately IOS isn’t very USB friendly so it rules mobiles out, but Android should work (not tested it myself though).

13

That’s supported too. On Linux it starts but haven’t managed to do anything with it and haven’t had energy to dig in either why it doesn’t work. Is the source code somewhere available?

14

You can configure inverters via VictronConnect, but the options are limited in comparison to VEConfigure. Why this has been a case for such a long time is unknown to me. I would expect feature parity at this point. VictronConnect has been out for a while.

That’s incorrect. You don’t have to disconnect VE.Bus. You can plug in the MK3 adapter to the second port on either the Inverter or GX device with no problem.

That has not been my case at all… I have left some systems unconfigured for a while and didn’t get any errors from the Pylontech batteries… what errors are you getting?

You should definitely update firmware in all devices, including the Inverter, when installing for the first time after unboxing. If you keep automatic updates disabled on the GX device (which is the default setting), you don’t need to update the firmware in the Inverter after that unless there is a specific recall issued by Victron.

If you enable GX auto updates, you might have to update the inverter from time to time… but this happens very rarely… the only time I had to do it was when there was a new MK3 firmware update for the inverter.

1 Like
15

One more thing about the update process of the VE bus inverters: it would be nice if the software can restore the previous configuration automatically to the inverter after firmware update, especially if the configuration isn’t very complicated (single phase, no assistants), especially when using user-friendly VictronConnect. Maybe if the configuration is more complex, there could be a warning window that the inverter has to be reconfigured manually before beginning the firmware update itself.

2 Likes
16

Once you start the program, the flash screen appears

image

It specifically says that “remove all connected accessories”. Those two exceptions don’t mention GX devices, but there is Color GX under the big X-denial.

I have used it when those were connected and I’m not sure why that is, I’d prefer to plug the MK3 at the end of the chain.

17

You can’t have both connected simultaneously. It causes issues.

1 Like
18

When I configure VE.Bus devices, I usually plug the MK3 adapter directly into Cerbo and don’t experience any issues.

I remember reading somewhere that this was issue with some old accessories but I have never experienced any problem myself.

19

It is not advised to do so. I plumb a spare cable for the mk3 and just disconnect the GX prior.
Some have left both connected which really does cause problems.

20

Those are two different things, what is been instructed by the manufacturer and what is done.